unreal4u's Personal Network » Pensamientos Personales

Algunas notas sobre el prefetching

unreal4u — Mon, 30 Jan 2012 21:29:17 +0000

Desde hace tiempo que sigo bien de cerca algo que me tenía bien intrigado: el prefetch de HTML5, que me parece demasiado buena idea y espero que todos los navegadores lo implementen ipso-facto. Sin embargo, quise echar una pequeña mirada a cómo funcionaba (si es que funcionaba) y específicamente a cuál era la sintaxis necesaria y cuáles son los pequeños trucos de la vida que se pueden aplicar para lograr el efecto deseado. Haz click en leer más para conocer los detalles de esta investigación que algunas sorpresas dio y también muchos dolores de cabeza.

¿Qué es el prefetching?

Desde la entrada de HTML5, aparte de los tags de audio y video, hubo algo que me llamó bastante la atención: el prefetch. Esta técnica consiste en adivinar lo que el usuario bajará en su siguiente click en nuestra página por lo que la idea detrás de esta técnica es bajar el mentado archivo o página desde ya para que de esta forma cuando el usuario haga el click no tenga que bajar el archivo nuevamente.
En teoría, suena bastante bien, pero quise llevarlo a la práctica para saber si acaso era factible o no poder implementar esta tecnología hoy en día. De acuerdo a casi todas las páginas web que consulté, simplemente había que incluir algunas cabeceras en nuestra página web para que milagrosamente funcionara el prefetching, lo cual me parecía demasiado bueno para ser verdad y así fue: resulta que el prefetching sólo ocurre bajo algunas condiciones y no siempre.

Como primer punto de aquiles, el prefetching sólo funciona en Firefox y en Chrome, desde la versión 3.6 y 13 respectivamente, pero sinceramente es un punto que poco importa, ya que estos dos navegadores juntos ya obtienen más de un 50% de participación en el mercado de los navegadores (fuente), por lo que nuestro grupo objetivo desde ya es bastante amplio.

Sin embargo, de aquí en adelante todo empieza a irse cuesta abajo. Resulta que el prefetching no funciona en muchos casos, y como podrán leer más adelante, el prefetching de Firefox simplemente no cumple su cometido, lo que baja nuestra cuota de mercado a sólo un 25%. La otra característica sobresaliente es que el uso más intenso que pretendía darle no funciona: sólo funciona si el recurso prefetcheado es un link (elemento ), y no una llamada ajax.

Preparación

Para poder saber de forma rápida si acaso el prefetching funcionaba, escribí 2 archivos: uno como índice principal y el otro de prefetching, con el siguiente código, primero vemos nuestro índice:



	Testing prefetch with HTML5
	
	
	

Please click here to display the (prefetched) page

Es un documento HTML5 estándar, con dos elementos link: uno para firefox (que ocupa rel=prefetch) y la otra para Chrome, que ocupa rel=prerender. Dato rosa: la diferencia entre ambas es que el prerender también renderea la gráfica de la página, mientras que el prefetch sólo realiza este paso cuando la página se hace visible. En un documento complejo podría quizás llegar a notarse este punto, pero para el 99,6% de las páginas restantes no habría ninguna diferencia. De todas formas, ambas directivas son necesarias, ya que uno funciona para Firefox y la otra para Chrome.

Sólo para realizar un test, tenemos dos "links": uno que carga el archivo mediante ajax, y la otra es simplemente un link. Hice esta separación ya que uno es dinámico y la otra es estática, y era probable que los navegadores hicieran una diferenciación entre ambos tipos.

Este será nuestro archivo que vamos a "prefetchear":

$fp = fopen('log.txt', 'a');
fwrite($fp,'['.strftime('%d-%m-%Y %T').'] - '.substr($_SERVER['HTTP_USER_AGENT'],strrpos($_SERVER['HTTP_USER_AGENT'], ' '),strlen($_SERVER['HTTP_USER_AGENT']))."\n");
fclose($fp);
sleep(3);
echo 'hello';

Por supuesto que tenemos un archivo llamado log.txt que tiene permisos 777. La principal razón del sleep era para simular la vida real y darle un tiempo de espera de carga de 3 segundos.

Empiezan las sorpresas

Con estos dos archivos empecé a hacer las pruebas, y grandes fueron mis sorpresas, ya que lo escrito en el papel es muy distinto a la práctica.

Primero dos links que me fueron de mucha ayuda:

http://browserspy.dk/prefetch.php

http://prerender-test.appspot.com/

El primero sirve para saber si el prefetching está funcionando para Firefox, mientras que el segundo sirve para verificar si el prefetching está funcionando para Chrome.
También resultó bastante útil el task manager de Chrome (Window|Task Manager), y este link, también para Chrome:
chrome://net-internals/#prerender

Ya con todas estas herramientas pude empezar a probar distintas configuraciones y estos fueron los resultados:

Firefox en Mac NO soporta prefetching. Así es, NO. Bajo ninguna circunstancia.
Firefox en Windows no tuvo mayores inconvenientes en hacer el prefetch, pero en cuanto se hace click en el documento "prefetcheado", lo empieza a descargar de nuevo. Más sobre esto después.
Chrome a partir de la versión 13 funciona bien el prerendering. ANTES de esta versión, no hubo caso en que funcionara.
Sólo se descargan documentos estáticos. Olvídense de pre-cargar ajax, no funcionará.

¿Qué pasa con Firefox?

Hasta que me di cuenta de lo que pasaba en Firefox, estaba feliz de que funcionara, pero me llevé una gran desilusión. Resulta que Firefox después de haber hecho el prefetching y cuando uno ya hace click en el link... empieza a descargar el documento de nuevo! El gran problema de esto, es que se pierde todo el objetivo de hacer un prefetching y más encima realiza un request adicional que nunca ocupará, gastando recursos en nuestro servidor.
Hay sin embargo un test que no he hecho y que tampoco creo que valga la pena: establecer cabeceras explícitamente en el futuro para que Firefox piense que el recurso que acaba de rescatar también es válido para el siguiente request.
El único reparo que tengo con esto es que si tenemos una cabecera de prefetching es por que sabemos que el próximo recurso a rescatarse será el que le estamos indicando... ¿para qué necesito decirle explícitamente que quiero que conserve ese recurso?

Conclusiones

Aunque Firefox soporta desde la versión 3.6 el concepto de prefetch, lo hace bastante mal. Uno pensaría que ya con tanto tiempo "soportando" prefetching, funcionaría bien pero como queda demostrado, lo soporta de forma paupérrima.
Chrome en cambio me alegró el día ya que funciona y bastante bien. Incluso funciona si tenemos un javascript como el que sigue:

var app = {
    prefetchLinks: function(){
        var hrefs = $("a.prefetch").map(function(index, domElement){
            return $(this).attr("href");
        });
        return $.unique(hrefs);
    },

    addPrefetchTags: function(){
        this.prefetchLinks().each(function(index,Element){
            $("", {
                rel: "prefetch", href: Element
            }).appendTo('head');
            $('', {
                rel:'prerender', href: Element
            }).appendTo('head');
        });
    },
};
$(document).ready(function(){
    app.addPrefetchTags();
});

Sacado (y modificado) desde esta página. Las modificaciones que tiene son en la llamada final de la función y en agregar el soporte para Chrome.

La gran sorpresa de esta función es que aunque construye bien el documento en todos los navegadores, el objetivo final sólo se logra en Chrome, ya que todos los demás navegadores no saben qué hacer con las etiquetas recién construidas, lo cual incluye -para mi sorpresa- a Firefox, que ni siquiera comienza a bajar los documentos que queramos rescatar.

Con esta pequeña investigación al respecto, creo que dejaré descansar el tema por uno o dos años para luego ver si se ha avanzado algo y si en ese futuro sirve o no.
También quiero dejar una pequeña enseñanza: aunque muchas páginas juran que el prefetching funciona con sólo agregar algunas líneas a tu código fuente, siempre hay que experimentar y tratar de hacer funcionar las cosas por uno mismo. En este caso, quedó demostradísimo que no es llegar y agregar links, ya que la funcionalidad final sólo se logra en un navegador mientras que para el otro es sólo una gastadera de recursos. Por si fuera poco, casi todas las páginas que promocionan el uso del prefetching sólo incluyen el código necesario para Firefox haciendo su solución totalmente inútil para la vida real, así que: cuidado con copy-paste!

Ventajas y desventajas de Mac OS Lion

unreal4u — Wed, 27 Jul 2011 04:45:27 +0000

La última versión del sistema operativo de la manzanita es, en muchos sentidos, un cambio para bien. Sin embargo, hay algunas cosas que no funcionan y otros que llegan a ser molestos y esta entrada pretende ser una suerte de guía para aquel que, como yo, simplemente actualizó a Lion sin leer antes de.

Una de las cosas que afecta directamente la temática de este blog, es que Lion actualiza la versión de PHP... y lo hace sin preguntar. Eso significa que tenemos que instalar php-mssql, xDebug, APC y todo eso nuevamente, así que aprovechando la ocasión, estoy escribiendo dos artículos a la vez: la primera que enseña a instalar xDebug y php-mssql (APC ya está cubierto) y esta misma.

Desventajas

Lo primero que se anuncia con bombos y platillos es que cambió el multitouch, pero este cambio se puede desactivar rápidamente en Preferencias - Trackpad - scroll & zoom - desactivar scroll direction: natural.

Con estos nuevos settings del multitouch lamentablemente también se perdió la habilidad de ir al inicio o final del documento con hacer el swap de tres dedos hacia arriba y abajo respectivamente. Sin embargo, buscando en Internet, encontré un programa llamado BetterTouchTool que vino a salvar el día. ¿Lo único malo? Hay que tener iniciado el programa lo cual no es tan terrible ya que queda en la barra del reloj:

Otra desventaja es que Visor, plugin para mejorar la terminal integrada, desapareció por incompatibilidad. Lo bueno es que buscándomelas, di con el sitio original y para mi sorpresa me di cuenta que Visor estaba descontinuado y que apareció TotalTerminal en su lugar, que hace lo mismo con una instalación más simple que Visor y que funciona de lo más bien con Lion. El único "detalle" es que no desaparece la ventana cuando pierde el foco como lo hacía con Visor, pero supongo que esa funcionalidad se restablecerá en una versión futura.

Sin embargo, la guinda de la torta es definitivamente la actualización a PHP5.3.6. Aunque se agradece el upgrade, podrían por lo menos haber avisado ya que me da una paja enorme tener que instalar las extensiones nuevamente. Lo único rescatable de esto es que mañana en la mañana estaré obligado a hacerlo ya que de lo contrario no tendría para qué ir a trabajar.

Ventajas

Las ventajas sin embargo son muchas más significativas que las desventajas. Entre ellas podemos mencionar detalles como por ejemplo que ahora se puede modificar el tamaño de la ventana desde cualquier lado y no solamente desde la esquina inferior derecha y otro tan gigante en Mail que simplemente deseché Thunderbird, ya que fue un amor a primera vista.
Todo lo malo de Mail (un poco desorganizado, sin soporte para conversaciones) ahora ya no es así y presentaron una interfaz mucho más limpia y novedosa. Por lo demás ahora soporta las conversaciones de una manera que incluso le podría hacer la competencia a gMail. ¡Incluso ahora tiene soporte para las famosas estrellas de gMail! (Que antes no tenía). En fin, como por lo general soy un asiduo fan a la búsqueda en mis mails y la búsqueda en Thunderbird da pena, me cambié inmediatamente de vuelta a Mail.

Por otro lado, Spaces desapareció pero en su lugar apareció Mission Control, que sería una cruza bastante extraña entre Spaces y Exposé. No lo he probado con múltiples monitores y extraño un poco la distribución customizada que uno le podía dar a las distintas pantallas con Spaces y Exposé, pero la configuración ahora es bastante más simple y además la pantalla de presentación mejoró bastante, aún teniendo muchos programas abiertos uno puede ver todas las ventanas sin problemas, algo que no pasaba con Exposé.

A medida que vayan pasando los días voy a ir encontrándole más cosas buenas y malas a Lion, pero hasta el momento mi experiencia ha sido bastante agradable. Es de esperar que siga así.

Manito de gato al blog

unreal4u — Sun, 17 Jul 2011 06:26:47 +0000

Hace mucho tiempo que quería hacer algunas cosas nuevas en el blog, entre las cuales estaban:

Una actualización general: Cuando instalé el blog WordPress iba en la versión 2.7.9 y nunca más la actualicé.
Actualización de Plugins: Aunque no me gusta ocupar plugins, sí tenía algunos que estaban sumamente desactualizados.
Incorporar botones sociales: Hoy en día, casi infaltables si uno quiere hacer las cosas de forma rápida.
Cambiar el blog de máquina: Antes estaba en una máquina casi exclusiva, ahora, estoy en el servidor web que sirve todas las páginas, pero podré administrar mejor.

Así que buenas noticias: actualicé WordPress a la última versión (3.2.1), actualicé los plugins a la última versión y también incorporé los botones +1 de Google, Like de Facebook y el Tweet Button de Twitter. Y para dejar algo de aporte, revise el código después del salto.

La verdad, pensé que incorporar estos botones iba a ser un poco más complicado, pero resultó bastante más fácil de lo que pensé. Lo primero que tenemos que hacer es visitar cada una de las páginas arriba mencionadas y seleccionar el estilo adecuado a nuestro gusto. Una vez hecho eso, procedemos a su instalación.

Botón +1 de Google

En header.php de nuestro theme, justo antes del cierre de la cabecera, agregamos el siguiente código:

Luego, para cuando queramos agregar el botón en algún lado, digamos single.php o index.php, sólo basta con:

size y href son obviamente configurables. Revisen también la página de Google, porque al incluir el primer javascript, es posible setear algunas configuraciones de inmediato, como por ejemplo el idioma.

Like de Facebook

Este botón es quizás el más difícil de estilar debido a que trabaja directamente con HTML en vez de CSS para eso. De todas formas, es bastante fácil, basta con agregar este código:

Pueden revisar las opciones que ofrece el botón en el mismo link que cité arriba, de las 3 opciones, es la mejor documentada.

Tweet Button de Twitter

De las tres, es la que peor documentación tiene, sin embargo, su inclusión sigue siendo, tal como los demás botones, casi un chiste de lo fácil que es.
Lo primero que tenemos que hacer es incluir el siguiente código en nuestra cabecera:

Y después, cuando queramos imprimir el botón:

Tweet

Y con eso, quedará inmediatamente insertado en nuestro blog.

Espero que les haya servido de ayuda para además, revitalizar un poco el blog.

Sobre convenciones y notaciones (húngara, CamelCase, etc)

unreal4u — Tue, 15 Mar 2011 04:25:32 +0000

Cuando el otro día escribí sobre PHPDocumentor, en los comentarios se mencionó que podría crear un post sobre las distintas notaciones que se utilizan comúnmente.

Lo primero que debo mencionar es que existen pocas notaciones, la verdad es que yo sólo conocía dos, y grande fue mi sorpresa cuando me di cuenta que sólo existían cuatro. Sin embargo, no deja de llamarme la atención la gran cantidad de convenciones que existen alrededor de las notaciones, que por lo general es una convención en cada empresa, adaptado específicamente a sus necesidades y requerimientos.

Lo primero por lo cual partir es establecer la definición de qué es una convención y qué es una notación. En muy pocas palabras, una convención es un conjunto de reglas que se aplican para lograr un consenso en la programación, de aplicar ciertas reglas de común entendimiento y de esta forma acelerar el desarrollo y lograr trabajar mejor en grupo. En ella se establecen por ejemplo qué reglas se aplican al nombramiento de las variables, de las constantes, de las funciones, de las classes, de los archivos, del árbol de directorios y un gran etc (que incluye también la notación a utilizar). En definitiva, una convención engloba una notación.

Una de las convenciones más comunes es aquella que dicta que las constantes deben ir completas en letras mayúsculas para diferenciarlas fácilmente de las variables. También es común encontrarse que los nombres de las tablas en la base de datos deben ir completamente en minúsculas y que la id principal en caso de tener debe incluir la palabra "id_" seguido del nombre de la tabla. (Y en bases de datos que lo permitan, el nombramiento de los índices debe ser "pk_*", "uk_*", "fk_*" para claves primarias, únicas y foráneas respectivamente). También he visto casos donde las tablas se ordenan con un sistema de 3 letras al inicio de cada una (prefix) de acuerdo a su función primordial. (Como por ejemplo: "sis_*" para todas las tablas que involucren directamente el sistema base, "bod_*" para todas las tablas que involucren movimiento de bodegas, "ven_*" para todas aquellas relacionadas con las ventas y así sucesivamente.
Volviendo al tema un poco más en general, en una convención también se establece si se ocupará algún sistema de control de versiones como GIT, SVN u otro, cada cuánto se subirá la información al servidor de producción y qué se hace en caso de desastre. Por lo general, para toda esta información se crea un documento o manual para consultarlo en caso de ser necesario, especialmente útil si hay 100 personas trabajando en un proyecto y de esa forma seguir un solo estilo único en toda la empresa.

Por otro lado, también se debe elegir el tipo de notación a ocuparse, entre las cuales existen:

Notación C

Es la menos conocida de los cuatro. Consiste en que básicamente los espacios se cambian por un guión bajo. Esto resultaba útil durante los años 60 donde podía pasar que escribir una mayúscula era más lento que escribir un guión bajo. Lo otro que llama la atención de este tipo de notación es que todo se escribe en letras minúsculas.
Se ocupó mucho en C y C++, aunque actualmente está en desuso. Personalmente, lo ocupo para elementos en HTML, ya sea para señalar ids de elementos, classes y otros. (Ejemplo:

Notación posicional

Otra notación bastante poco conocida hoy en día (pero que en sus tiempos fue famosa) es ésta que se ocupaba primordialmente en ambientes limitado por el famoso 8.3 (el que sea old-school va a saber al tiro, el que no, que investigue. Pista: DOS) que también se aplicaba a algunos lenguajes de programación.
Esta restricción también se aplicaba a algunos lenguajes de programación. De esta forma, (y el único ejemplo que pude encontrar en la red), el nombre de una variable sería LCCIIL01, donde LC sería la aplicación, C para denostar Cobol, IIL para señalar el sub-proceso y 01 era una secuencia.

Notación CamelCase

Es quizás la más famosa y la que, aparte de los lenguajes de programación, también se le he visto fuera de estas. Existen en principio dos variantes de esta notación, la UpperCamelCase y la lowerCamelCase. El que tiene un ojo agudo va a conocer la diferencia de ambas sólo con leer el nombre mediante la cual se diferencian, pero para el ojo menos experto le diré que la principal diferencia entre ambas es que en el caso del upper la primera letra siempre se escribirá en mayúscula mientras que en la segunda la primera palabra siempre será entera en minúsculas.

Notación Húngara

El inventor de esta notación (Charles Simonyi) nació en Hungría, por eso el nombre. Aunque personalmente debo decir que deberían haberlo llamado notación Simonyi ya que el caballero mencionado es demasiado seco, vean el link de arriba si no me creen.

En fin, volviendo al tema, la notación húngara está basada en parte en CamelCase, específicamente la lowerCamelCase. En su versión más básica, tenemos varios tipos de datos los que reciben una letra. De esa forma, un string recibirá la letra s, un int la letra i, un decimal la letra d. Un arreglo recibirá por supuesto la letra a.
Teniendo eso en cuenta, y combinándola con la CamelCase no resulta difícil pensar en qué sigue: Un nombre cualquiera para nuestra variable siguiendo las reglas del CamelCase.

De esta forma, podemos tener:
aIndicadorResultados
iContador
sPrimerNombre

Y así se continúa. De esta forma, con sólo un miro podemos saber de qué tipo es nuestra variable, y mediante CamelCase (asignándole un nombre significativo) podremos saber cuál es su función, lo cual encuentro ideal en un lenguaje como PHP donde una misma variable puede ser un float o un bit al momento siguiente.

Para finalizar, cabe destacar que los 3 tipos mencionados no son los únicos, para ver los restantes, favor visitar la nunca mal ponderada wikipedia donde se explica con muchos más ejemplos y más profundamente el uso de esta notación.

Espero que les haya servido el artículo.

El problema del microsegundo en MySQL

unreal4u — Tue, 15 Feb 2011 16:00:49 +0000

Es increíble cómo hoy se celebran 6 años desde que fue ingresado un feature request a MySQL Bugs pidiendo que se implemente una función que de seguro es importante para muchos: los microsegundos en TIMESTAMP y otros relacionados.

Si bien es cierto que por lo general no se necesita tanta precisión, de repente es necesario, ya sea para propósitos de debug o actividad en el sistema, considerando que es un sistema que ocupan muchas personas.
Imaginemos por un momento que administramos Facebook y ocurre lo peor que te puede pasar: uno de los balanceadores de carga entiende mal un request y arma un castillo de naipes sobrecargando paulatinamente cada uno de los servidores.

Enseguida vienen las preguntas: ¿Es un bug? ¿De dónde viene? ¿Fue provocado por algún usuario? ¿Por cuál? En estos casos críticos es necesario conocer en qué momento exacto las cosas comenzaron a fallar, ya que un segundo es un espacio de tiempo demasiado amplio: es posible que caigan 2 o más servidores en ese mismo segundo y hay que encontrar el origen, aislarlo, arreglarlo y asegurarse de que no vuelva a pasar, pero para eso, se necesita saber qué usuario hizo qué cosa como para que empezaran a caer los naipes.

Algo parecido me pasó ayer con la aplicación de la empresa: apareció un error en el log del sistema. Todos los errores de PHP los capturo y los guardo en la base de datos, aunque muchas veces no tengo idea de a quién le salió el error debido a que todavía no depuro mucho la parte que es la encargada de revisar la sesión anteriormente existente y rescatar la información desde ahí. Hasta el momento tampoco me había preocupado mucho, ya que se logea la hora en que se produjo el error y además se logea la actividad del usuario: si al usuario en cuestión le apareció un error, voy a poder filtrar por la hora en que se produjo el error si fue él o no.

Sucede que por esas cosas del destino, revisando a quién le podría haber salido el error, me di cuenta que al filtrar por la hora habían dos posibles candidatos, momento en el cual me di cuenta que se hizo posible mi worst-case scenario: dos usuarios distintos que visitaron la misma página en el mismo segundo. ¿Quién había provocado el error?
Para complicar las cosas aún más, esos dos clicks no eran los únicos: también había una redirección de parte de uno de los usuarios, lo cual puede significar varias cosas. En total, para ese segundo en particular, ahora tenía 5 registros: 2 actividades de usuarios distintos, una redirección y el landing page de esa redirección, además obviamente del error. Para agregarle más enredo, no se sabe bien en qué orden ocurrieron las cosas debido a que MySQL internamente ordena las cosas de acuerdo a su propio criterio y no de acuerdo al microsegundo en el cual ocurrieron las cosas. (Para optimizar esa tabla que presenta una altísima actividad [para hacerse una idea: son 100 usuarios activos + 50 vendedores de campo que continuamente están ingresando ventas, revisando flujo de caja, revisando las cuentas de la empresa, viendo logística y un montón de etcétera], no tiene un simple id_actividad AUTO_INCREMENT asociada, sino una clave primaria compuesta entre varios campos importantes, entre ellas la hora).

Ok, mucho blabla, ¿qué puedo hacer para solucionar esto?

Lamentablemente, y como una solución "óptima" no mucho. Existen algunas soluciones pero ninguna es efectiva debido a que el origen de ellas no es en MySQL mismo, sino que el origen se genera afuera de la base de datos, lo cual supone unas cuantas complicaciones que ya veremos. Pero veamos primero cómo podemos almacenar microsegundos.

Llegué a dos potenciales soluciones, de la menos a la más recomendada son:
- Lo primero es tener una tabla donde la fecha que guardaremos se almacene en formato UNIX_TIMESTAMP como un bigint o un numeric (decimal) con la cantidad de dígitos "microsegundianos" que queramos almacenar. Desventajas? Al guardar como un número se pierden todas las ventajas de consultas un poco más complejas, como aquellas que incluyen MONTH(), DAY() y demases. Tampoco se pueden calcular rangos de fechas y otro montón de funciones más. Al menos para mi, se pierde demasiado comparado a la poca ganancia de los microsegundos.

- La segunda solución consiste en guardar la fecha en dos campos por separado: la primera siendo un campo de tipo TIMESTAMP y la segunda siendo un INT del largo que deseemos. Supongamos que queremos guardar 6 dígitos significativos, por lo tanto nuestro rango iría de 0 a 999.999, un número que alcanza a ser guardado en un MEDIUMINT sea UNSIGNED o no. (Por favor tened esta página como referencia). Ahora, si queremos ordenar por microsegundo, en nuestro ORDER tendríamos que colocar: ORDER BY UNIX_TIMESTAMP(campo_timestamp),campo_microsegundo. ¿Fácil, cierto?

Y vienen los problemas...

La segunda solución sería ideal si no fuera por un pequeño detalle: ¿de dónde podemos sacar el dato del microsegundo? Una cosa es segura: NO a través de MySQL. Prueben con las siguientes variantes:

SELECT MICROSECOND(NOW());
SELECT MICROSECOND(CURRENT_TIMESTAMP);
SELECT EXTRACT(MICROSECOND FROM NOW());
SELECT DATE_FORMAT(NOW(),'%f');

¿Qué devuelve? Les simplifico la respuesta: 0 (Cero). En todos los casos. Punto. NO HAY forma de sacar el valor del microsegundo exacto en MySQL. Es un dato que siempre provendrá del exterior.
Ahora bien, en sí eso no es mucho problema porque siempre nos queda la opción de generarlo con PHP. Con un poco de suerte PHP y MySQL estarán en el mismo servidor así que la hora y el microsegundo siempre estarán coordinados... ¿pero qué pasaría si están en máquinas separadas? O peor aún, ¿si entremedio le metemos un balanceador de carga para el webserver?
Respuesta corta: termino con una ensalada de microsegundos que no corresponde a la realidad, ya que una máquina tendrá una hora distinta de otra y además esa hora difiere de la hora del servidor de base de datos. Además hay que tomar en cuenta que en promedio un servidor tiene un margen de error de 3 segundos por año (en el mejor de los casos, tuve que arreglar hace poco un server al cual no se le sincronizaba la hora hacía 9 meses y tenía un desfase de 574.473159 segundos, seguramente porque entremedio de esos 9 meses hubo una hibernación que Linux no considera como tiempo que pasa) es casi imposible que a nivel de microsegundos una fecha pueda ser certera.

En el escenario más probable, un sistema grande, con muchos usuarios y carga, teniendo un balanceador de carga y 2 personas visitando una misma página al mismo tiempo, es que se los mande a dos webservers distintos, dando como resultado, 2 horas (microsegundianamente visto) totalmente distintas, ya que una diferencia de hora de 0.05 segundos ya da resultados muy distintos.

Como conclusión... es que espero que MySQL, después de 6 años incorpore de una buena vez el microsegundo como parte de un campo TIMESTAMP, TIME o DATETIME. (En lo personal, que lo dejen dentro de TIME que sería la aproximación más exacta a lo que se quiere lograr). Y por mientras los usuarios "comunes" de MySQL simplemente tendremos que conformarnos con soluciones parches como el expresado arriba o bien cambiarnos a PostGreSQL que sí tiene soporte para este y muchos otros tipos de datos más, donde en temas de tipos de datos para trabajar con monedas o direcciones ip's están a años luz de MySQL. (No saben los dolores de cabeza que he tenido porque MySQL no me permite guardar 192.168.1.0/28 y tengo que generar y guardar el intervalo de forma manual).

Algunos links interesantes

unreal4u — Fri, 04 Feb 2011 03:23:00 +0000

Como siempre, navego en busca de información interesante, y aquí les traigo algunos links de interés (que además me servirán para desocupar un par de pestañas del navegador). Están ordenadas por temática, y hay de todo un poco, desde generadores de passwords hasta guías sobre cómo hacer extensiones de classes para Magento.

jQuery / Javascript:
Una botonera hecha con jQuery y cuyo efecto me encantó.
Ordenar un arreglo con drag & drop, enviando una solicitud via Ajax al server principal.

PHP:
Cómo crear un daemon en PHP, excelente artículo.
Comprendiendo cómo ocupar closures en PHP.
Del mismo blog, aprendiendo cómo usar Reflection en PHP.
Desde DeveloperWorks, un artículo que explica cómo optimizar PHP en 5 simples pasos, bastante básico pero certero.
Interesantísimo artículo de cómo ocupar Memcached, APC y/o directamente el sistema de archivos.

MySQL:
Del blog personal del creador de menéame, explica cómo optimizó una consulta en el transcurso de 5 años. Mención aparte se lo llevan los comentarios donde aprendí varias cosas nuevas.

WordPress:
Una guía bastante buena que nos enseña cómo optimizar (y asegurar) wp-config.php, ese archivo tan vital de WordPress.
¿Quiéres saber cómo funciona WordPress y su sistema de funciones? Échale un miro a este post donde definen 35 funciones (bastante) útiles para WP.

Magento:
La mejor manera de trabajar en Magento: extendiendo classes. Por lo mismo, no te puedes perder este artículo donde se explica con bastante detalle cómo crear una extensión.

CSS:
Completo listado de todas las propiedades de CSS y cuáles son soportadas en sus distintas versiones.
Una guía acerca de los pseudo-selectores de CSS, lectura recomendada para aquellos que quieran sacarle el jugo a CSS.

Misceláneos:
¿Alguna vez has tenido que armar una página con un mapa de Google Maps y tienes que averiguar las coordenadas? Bueno, entonces sabrás el dolor de cabeza que representa averiguar las mismas, hasta ahora. Sólo basta ubicar bien el puntero en esta página especialmente dedicada a tal propósito y estás listo: ¡ya tendrás esas coordenadas!
¿Necesitas generar una contraseña segura de forma rápida? Sin duda que esto te ayudará mucho.

phpDocumentor: Haciendo una buena documentación excelente

unreal4u — Wed, 26 Jan 2011 01:32:54 +0000

No fue sino hasta el otro día que le encontré un propósito y una utilidad a la documentación bien hecha.

Todo surgió debido a que andaba buscando un método determinado que había escrito una vez hace 5 meses atrás y que podría haber estado dentro de un par de classes o bien dentro de un par de archivos de distintas funciones: en resumen, no tenía idea de cómo se llamaba ni menos cómo se ocupaba. Incluso ni siquiera estaba seguro de si efectivamente podría hacer lo que tenía pensado ya que la función que había escrito hacía algo muy parecido, pero podría ser que no hiciera lo mismo. Traté de ubicarla mediante diversos términos con este script pero no hubo caso. Ya casi dándome por vencido se me ocurrió la idea de que en realidad la documentación del programa estaba mal hecha y con múltiples formatos distintos: había que unificar todo.

Fue entonces que me puse a buscar estándares de documentación donde, al parecer, Java es definitivamente la número 1 con su JavaDoc, esquema que fue copiado por PHPDocumentor (y que convenientemente pasó a llamarse PHPDoc). Básicamente hay que seguir algunas reglas, las cuales son:

/**
 * Un comentario PHPDoc siempre empieza con 2 asteriscos. Comentarios adicionales tendrán 1 asterisco
 *
 * La primera línea será siempre una descripción corta, es como el título
 * Si se desea agregar o extender esa descripción, es necesario un espacio en blanco
 * y luego una descripción un poco más larga que dura hasta el siguiente
 * espacio en blanco.
 *
 * @author PHPDoc es capaz de recibir varios parámetros, entre los más importantes, el autor...
 * @param string $asdf En caso de funciones, los parámetros que recibe esa función
 * @return bool O lo que retorna esa función
 * @version 0.1 También podemos dejar expresado la versión
 * @package Y una de las más importantes: agrupar contenido por packages
 * @subpackage Y por supuesto por sub-packages.
 */

Existen bastantes variantes más de etiquetas que podemos poner, que están listados aquí, página en la que además se explica mucho mejor el uso básico de PHPDoc.

En fin, una vez que unifiqué todos los comentarios, había que generar la documentación. Para esto, bajé PHPDocumentor, configuré la configuración predeterminada ubicada en user/default.ini a mi gusto con las rutas y visité la página predeterminada que crea PHPDocumentor. Pasó un buen rato y terminé con mi documentación en un esquema muy parecido a esto (elegir alguna opción de las disponibles).

PHPDocumentor genera entonces toda la documentación técnica en un formato fácil de leer y fácil de seguir para el programador, desde donde es perfectamente posible combinarlo por ejemplo con las keywords propias que genera svn.

De esta forma, es posible generar un completo manual para el desarrollador el cual podrá ser estudiado y eventualmente hasta auditado (y por supuesto aprobado) por alguna empresa externa.

Así que ya saben: no existe excusa alguna para generar una buena documentación... y hacer de esta buena documentación una excelente documentación.

Histórico: se han superado 1.000 visitas mensuales!

unreal4u — Sat, 13 Nov 2010 04:30:25 +0000

Sé que este post lo más probable es que no le interesa a nadie, pero de todas formas siempre es bueno celebrar un límite mental, el cual es, en este caso, el tráfico de 1.000 visitas únicas mensuales. Aunque el 80% de las visitas abandonan la página, hay un puñado de 25% que se queda frecuentemente dando vueltas en el sitio y les agradezco

Sin más ni menos, les presento el SS que demuestra lo que estoy diciendo:

Recuperándome del desastre: Rollback de 3 meses

unreal4u — Mon, 08 Nov 2010 15:49:22 +0000

Estaba anoche trabajando en varias cosas, entre ellas ver la forma de actualizar mi instalación de WordPress. Como siempre se aconseja respaldar todo, respaldé todo lo que eran datos del disco y por supuesto ejecuté lo que yo creía que era un mysqldump (para respaldar) pero me equivoqué en esto último, restaurando el último respaldo que saqué cuando me cambié de hosting, es decir, hubo un rollback de cerca de 3 meses.
Sucede que siempre he tenido la costumbre de respaldar periódicamente la base de datos: para esto, ejecuto un simple "mysqldump -p db_wp > respaldo.sql" mediante la cual rescato la base de datos "db_wp" a respaldo.sql. En un Linux cualquiera, para no ingresar el comando a cada rato, es simplemente flecha hacia arriba durante un rato para encontrar el comando y darle enter. Hasta ahí no hay ningún problema, sólo que hace poco me cambié de hosting y nunca había hecho un respaldo: sí había importado la base de datos cuando me cambié por lo que el comando guardado era "mysql -p db_wp < respaldo.sql". Muy poca diferencia para las dos tremendas diferencias que hay entre ambas.

Como es bastante desilusionante perderlo todo, voy a aprovechar el espacio para aconsejar qué hacer en caso de desastre.

Si tienes habilitado el log binario de mysql, estás salvado: en ella se guardan todos los datos, incluso los que pasaste a borrar con un "DROP TABLE usuarios". Ojo que puede no servir para condoros que impliquen gigas de información. Revisen en Google acerca de mysqlbinlog. En mi caso no existía este archivo
Soñar para que el administrador de turno haya activado un respaldo diario. Aunque en teoría debería haber estado haciéndolo, este servidor se instaló hace poco y al parecer nadie se acordó de activar esto
Confiar en la caché de Google: aunque la gran mayoría de los artículos estaban online, los últimos 3 no estaban
Publicar los artículos completos en tu RSS y salvarlos desde ahí.

Aunque no lo crean, fue esta última opción la que me salvó, pero eso sí: se perdieron los comentarios Sin embargo, agradezco a Thunderbird por ser lo suficientemente inteligente como para no borrar los artículos siendo que el RSS "nuevo" que había no tenía aquellos artículos.

Es así como se restauraron los artículos de los últimos 3 meses y estamos con los artículos actualizados. Tengan por seguro que NO me volverá a pasar lo mismo

Google Hell: qué es, cómo evitarlo… y cómo salir

unreal4u — Thu, 04 Nov 2010 03:02:35 +0000

Algo pasó durante el fin de semana que de pronto al buscar por Google Hell aparezco en los primeros lugares... así que aprovechando el impulso, voy a explicar un poco mejor de qué se trata, cómo evitarlo y cómo salir de ella... si tienes suerte. (Y paciencia).

Google Hell (traducido: el infierno de Google o GInfierno) fue un término acuñado porque de pronto el gigante buscador simplemente puede decidir dejarnos fuera de su índice principal, relegando nuestras propias páginas a meras búsquedas del tipo "site:misitio.com busqueda", algo que se conoce como el índice suplementario. También existe la posibilidad (menor, pero posibilidad a fin y a cabo) de que nos banee y nos ponga en un blacklist.
Por este hecho, es probable que de pasar a ser siempre los número 1 en casi cualquier búsqueda, pasemos directamente a la página 300, con suerte: aquella última página que nadie visitará y por lo tanto, reducirá las visitas en un (en mi caso) casi 65%. Auch.

¿Cómo evitar el Google Hell?

No indexándote en Google. No, fuera de bromas, existen bastantes técnicas que puedes evitar:

Intercambio de links: Pecado mortal. Si pagaste para que de la noche a la mañana te llenaran de links entrantes... puedes olvidarte con certeza de que aparezcas primero en todos los sitios. Más información en el cuarto ítem.
Páginas duplicadas o hasta dominios duplicados: Creo que nunca he tocado este tema en el blog, pero un pecado gigantezco (aunque no tan grande como el anterior) es tener los dominios (ejemplo) www.unreal4u.com y unreal4u.com por separado sin redirigir a alguno en particular. Google considera que sólo estás tratando de duplicar las páginas para que de esta forma, aparezcas mejor rankeado. El cómo evitar esto será objeto de un próximo post.
Títulos duplicados: Es casi lo mismo que lo anterior, pero menos grave. Inscríbase en Google Webmasters para ver esto.
Páginas en blanco: Uno de los pecados más grandes a realizarse es tener páginas en blanco. Sucede que hace algún tiempo atrás, existían muchas páginas que tenían un montón de comentarios (que el navegador ignora) con una montonera gigantezca de links. Esos links para Google eran relevantes, hasta que se dieron cuenta de lo que pasaba y desde ese entonces que página en blanco significa un pasaje casi directo al Google Hell.
Cabeceras 404: ¿Alguna vez has creado una página 404 personalizada? ¿Se ve bonito cierto? Pensarías de cierta forma que Google aprecia esto, y es cierto... siempre y cuando mandes el código 404! Sucede que el ErrorDocument redirige el request al 404, haciendo que de esta forma, el 404 en realidad se transforma en un 200... al tener muchos 404 tendrás mucho contenido duplicado... mucho contenido duplicado significa Google Hell.
Crear robots.txt y sitemap.xml: Estos dos archivos son muy útiles para los buscadores... sé amigable con ellos y créalas.

Cómo salir del Google Hell

Si has llegado hasta aquí... no hay mucho más de lo que pueda aconsejar que no sea seguir los consejos de arriba. Arregla el sitio, ten ojo, revisa en Google Webmasters, manda sitemaps como loco y reza para que Google no decida dejar pasar un año antes de dejarse caer nuevamente con su Googlebot. ¡Y nunca compres intercambio de links!