unreal4u's Personal Network

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!

Índice de directorios con filtro

unreal4u — Sun, 04 Dec 2011 19:41:16 +0000

Hacía mucho tiempo que no escribía y era por una razón bien práctica: me cambié de país y como tal, he estado muy ocupado tanto con la mudanza, con el traerme mi mujer y trabajando, ya que de alguna forma hay que mantener la máquina andando y eso significa que aparte de todos los trámites regulares que hay que hacer y pagar, también hay que trabajar.

Lo bueno es que estoy trabajando hace cerca de 2 meses ya, encontré trabajo sumamente rápido y como recién llegado en la empresa, me llenaron de proyectos pasados, presentes y futuros. Cuando estaba trabajando en Chile, sólo tenía 3 proyectos permanentes, así que trabajar en localhost era bastante simple. Sin embargo, ahora tengo algo más de 18 proyectos y recordar el nombre de cada una no es tan simple como parece. Por eso, ya instalado en mi nueva casa y aprovechando un ratito de ocio, escribí un script que recorre un directorio y crea un link por cada directorio que encuentra para que de esa forma, pueda visitar http://localhost/ y hacer click en el proyecto que me interesa trabajar. Hasta ahí, no tiene ninguna maravilla; sin embargo; este script tiene algo especial, ya que permite esconder ciertos directorios y asignarles un alias a otros para que el listado no quede tan feo a primera vista.

En sí, consta de 2 archivos: un index.php y un .index (predeterminadamente el "." indica que se trata de un archivo oculto en los UNIX).

Veamos el primer archivo:

Proyectos en unreal4u
Proyectos
Edit .index for index options
'.$linkText.'';
		}
	}
}
echo $output;
?>

En ella primero abrimos nuestro archivo .index y creamos un pequeño arreglo con los datos (válidos) que rescatamos de ella. En seguida, abrimos el directorio actual y empezamos a recorrerlo verificando primero que se trate de un directorio y que no sea un archivo oculto (o el directorio actual). Si estas condiciones se cumplen, se verifica por último en nuestro arreglo si tiene un alias y si debemos esconderlo o no. Si no lo debemos esconder, lo mostramos.

El segundo archivo es bastante simple, es un archivo en texto plano que indica el nombre del directorio y un alias. Opcionalmente, el alias lo podemos nombrar con "." para que de esa forma lo esconda. La estructura sería:

# Hide logs and sessions folder
logs-sistema|.
sesiones|.
RemoteSystemsTempFiles|.

# Assign alias to some folders
00.general-tests|+++ Test Dir +++
doc|Technical Documentation
framework|Framework
zf|Práctica Zend Framework

De esta forma, cuando visitamos localhost, tendremos la siguiente vista (a la izquierda navegador, a la derecha explorador de archivos):

Espero que les haya servido el tip, en cuanto tenga más tiempo escribiré más tips y continuaré un poco con la actualización más constante de este blog.

Cinco maneras simples de acelerar tu aplicación

unreal4u — Thu, 22 Sep 2011 20:39:22 +0000

Estaba yo revisando mi twitter el otro día cuando me encontré con un artículo bien interesante acerca de cómo acelerar tu aplicación en PHP. De hecho, lo encontré tan bueno que decidí hacer el mismo listado, pero en español y poniéndole también de mi cosecha.

Instalación de un Opcode Cache

En general, se puede acelerar mucho una aplicación hecha en PHP con un simple programita, el cual es tan bueno que será incluida dentro del core de PHP en su próxima release principal (5.4). El funcionamiento básico de este programa sigue un esquema bastante básico, aunque para entender eso primero deberemos entender el cómo funciona el ciclo de entrega de una página Web. Básicamente, el ciclo completo es el siguiente:

Primero se pide la página, y esa petición le llega al WebServer. El mismo webserver, al detectar código PHP, se lo deriva a PHP, que revisa el código, lo parsea, lo compila y lo ejecuta, para entregar una salida. Por razones que desconozco, este ciclo se repite siempre, aunque el archivo no se haya modificado entremedio; o al menos; lo hará hasta la versión 5.4 de PHP, cuando se incluirá de forma predeterminada APC (Alternative PHP Cache). APC es además mantenida por varios desarrolladores de PHP, Facebook y Yahoo, así que comparado con las demás opciones es poco lo malo que se puede decir del mismo.

Lo que hace esta extensión es guardar una copia del script ya compilado, de forma que se evita algunos pasos innecesarios. Si el script fue modificado, entonces se compila nuevamente, pero hay que destacar que una vez que un sistema está estable, eso ocurrirá tarde mal y nunca:

Instalar un Opcode Cache es definitivamente una de las mejores soluciones que se pueden implementar: por lo menos un incremento de velocidad de un 80% en cada request.

Optimización de configuración de PHP

Hay diversas optimizaciones que se pueden hacer en la configuración de PHP, partiendo por las más básicas y también de forma más avanzada.
De las más básicas, son diversas las que no sólo incrementan la velocidad, pero también aumentan la seguridad:
register_globals: Lo mejor es dejar desactivada esta opción, ya que aparte de tener que parsear todo el script para buscar las variables, es una falla de seguridad enorme.
register_long_arrays: Habilita o deshabilita las variables tipo $HTTP_*_VARS que ya no son válidas hace mucho tiempo. Se recomienda dejar desactivado. (Off)
register_argc_argv: También se recomienda dejarla en off. Crea los arreglos argc y argv cada vez que un script se ejecuta, algo totalmente innecesario en el 99% de los casos, y en aquellos casos donde sí es necesario (CLI) se crean automáticamente debido a que son obligatorios.
auto_globals_jit: Se recomienda dejar en "On". Inicializa las variables superglobales ENV y SERVER sólo cuando se necesitan en vez de siempre. Las tres funciones previas deberán estar todas desactivadas para que este parámetro tome efecto.
magic_quotes_*: Esta opción originalmente existía para limpiar las entradas a las bases de datos, pero la gran mayoría empezó a implementar sistemas propios de limpieza de datos que eran mucho más efectivas y que protegían incluso de las inyecciones más comunes de las cuales los magic_quotes no protegían y al final cayó en desuso. Es también importante para la velocidad debido a que no se tienen que parsear las cadenas antes de enviarlas a la base de datos.
always_populate_raw_post_data: Nunca ocupé esta opción y no tengo idea para qué sirve. Sólo sé que deja una copia de todo el POST en otro arreglo, un duplicado. Predeterminadamente, esta opción viene desactivada desde PHP4.2.3.
output_buffering: Esta opción debería dejarse siempre activado, ya que evita que con cada llamada a echo o print se devuelva algo al navegador. Con esta opción en cambio, se llena un buffer y recién cuando ese buffer se llena o el motor de PHP termina de procesar la página, se manda toda la información en el buffer.
variables_order: Esta opción es poco documentada lo cual es una pena, ya que permite desactivar cierto tipo de variables superglobales. Predeterminadamente, está ajustada en EGPCS (Environment, Get, Post, Cookie y Server) y perfectamente podemos desactivar una o más de una. La que siempre he visto que es seguro quitar, es la E de environment. Casi nunca he visto que ocupen esa variable superglobal. El incremento en velocidad se obtiene al no tener que parsear en cada request esta variable superglobal.
date.timezone: Esta directiva fue introducida a partir de PHP5.1 y es bastante útil colocarle un valor predeterminado ya que sino se producirá un error de tipo warning en cada request. Este error se escribe en el disco, haciendo más lento el acceso general sobretodo en un sitio con alta demanda, y además PHP hará una serie de requests al sistema operativo para averiguar el valor.
short_open_tag / asp_tags: Recomiendo encarecidamente dejarlas ambas en off. ¿Lo malo? No podrán iniciar un documento php con " implicit_flush: Se recomienda dejar esta opción siempre en "off", ya que de lo contrario se ejecutará una llamada a "flush()" cada vez que se imprima un echo, un print o se haya enviado un bloque de información, algo totalmente innecesario en el 99% de los casos. (Y en aquellos casos donde sí es necesario, simplemente se hace una llamada manual a esta función).

Controlar las llamadas a require e include

Por muy increíble que parezca, la siguiente regla es definitivamente una de las más importantes. Es increíble cómo una aplicación anda mucho más rápido al controlar bien el flujo de nuestra aplicación y no abusar de include_once() y require_once(), que lo único que hacen es revisar en la pila si el archivo ha sido incluido, si las funciones que aparecen en ese archivo ya fueron inicializados, si las classes que declaramos ya fueron declarados previamente y finalmente levantar un error (en el caso de un include o require simple) u omitir el error si hacemos la llamada con *_once().
Así que ya saben: ¡a revisar bien su flujo y que no haya ninguna llamada con *_once() que hacen nuestra aplicación mucho más lenta!
Además, algunas micro-optimizaciones incluyen el usar rutas absolutas para no buscar en todo nuestro include_path y tratar de mantener llamadas estáticas en vez de dinámicas para poder permitir al motor de PHP tener eso en cuenta antes de ejecutar y poder hacer una suerte de pre-fetching. (Ok, no ocurre exactamente así, pero mantengámoslo simple).

Optimiza tu base de datos

Y llegamos al punto más crítico del artículo, el cual es tan extenso que perfectamente podría entrar en un post aparte.
Sólo mencionaré muy por encima las principales demoras en una base de datos:

Mal diseño de la base de datos. Definitivamente con esto podemos sepultar una aplicación al no tener un buen diseño pensando en el futuro en mente. Quizás hoy tenemos 100 registros, pero una vez que nuestra aplicación se lance, en pocos días podemos tener 250.000 registros en un día. Si un mes tiene 30 días, ¡tenemos que en dos meses podemos acumular 15.000.000 de registros! Índices y claves primarias cobrarán vital importancia.
Mal diseño de nuestras consultas. Muy similar a lo anterior, pero esta vez enfocada a la optimización de las consultas que le hacemos a la base de datos. Si hacemos un UNION de 15 tablas distintas, entonces anda preparanda esa tasa de café, porque la necesitarás. Lo mejor para solucionar este tipo de problemas es tomar un buen conector de base de datos y poner un EXPLAIN antes de nuestra consulta. (Ejemplo: si la consulta fuera SELECT * FROM t1; tenemos que escribir EXPLAIN SELECT * FROM t1;). Enseguida, MySQL, PostGreSQL u otro motor compatible con el estándar SQL99 nos explicará qué fue lo que hizo y en base a eso puedes reformular tu consulta.
Una conexión por consulta: He visto que hay gente que se conecta a la base de datos, hace una consulta y luego se desconecta. Luego, en el mismo request, se conecta a la base de datos y luego se desconecta. Así 50 veces más. En mi experiencia a lo largo de los años es que si hay algo costoso en términos de base de datos es logearse y obtener una conexión. ¡EVITA múltiples conexiones y trata de establecer sólo una por request!

Cachear datos

Otra de las más grandes optimizaciones que uno puede hacer, es ahorrarse consultas a la base de datos y jugar con la caché, ya sea generándola uno mismo u ocupando activamente APC u otro motor de caché (memcache, Wincache, etc). Eso si hay que tener en cuenta que a partir de la próxima versión mayor de PHP se incluirá predeterminadamente APC.
Volviendo a nuestro tema, la gran diferencia entre estos dos métodos (generando uno mismo la caché vs ocupar APC) es que mientras que en el primero por lo general guardamos código HTML ya listo y generado, en el segundo simplemente guardamos datos de PHP en memoria compartida. Esto último tiene algunas ventajas ya que primero que nada no tenemos que leer un archivo ya que ya se encuentra en memoria. Lo otro es que perfectamente podemos guardar un arreglo y por supuesto podemos cambiar la apariencia de ese arreglo sin tener que necesariamente ejecutar la misma rutina para generar ese arreglo. En este sentido, supongamos un menú lateral cuya estructura base es la misma pero cuyo HTML va cambiando ya que va resaltando el menú actual donde estamos, que en el fondo es otro HTML.
Claro, podríamos guardar estos datos por ejemplo en una sesión, pero eso de todas formas implica un llamado a archivo que es lo que queremos evitar.

Espero que les haya gustado esta entrega de optimización y micro-optimizaciones, sobre el cual ya tenía un artículo previo que hace mucho tiempo está en el blog y nadie pescó.

Fuente: developerWorks

Instalación de php-mssql y xDebug en Mac OS Lion

unreal4u — Thu, 28 Jul 2011 05:01:22 +0000

Ayer les contaba acerca de que Mac OS en su nueva versión del sistema operativo había actualizado la versión de PHP (sin preguntar) y que tenía que instalar las extensiones de nuevo. Hoy toca el día en que el artículo que explica cómo instalar dos de las extensiones más populares bajo este sistema operativo y con la nueva versión de PHP incluida.

Lo primero que hay que hacer es bajar las dependencias:
Freedts
PHP5.3.6
xDebug
Descomprimen todo en un directorio y hacen click en Continuar Leyendo.

Lo primero que tenemos que hacer antes de continuar es instalar Xcode que ahora está cómodamente disponible en la App Store. Ojo que una vez instalado (según la App Store) necesitaremos ir a Aplicaciones y apretar el ícono que dice "Instalar Xcode" para que todas las herramientas de desarrollo estén disponibles.

Ejecutamos los siguientes comandos. Ejecutar todo lo que esté con asterisco como root o con sudo, como quieran:

cd freetds-XXXX/
./configure --prefix=/etc/freetds --with-tdsver=8.0 --sysconfdir=/etc/freetds/conf/
make
# make install
# cp modules/mssql.so /usr/lib/php/extensions/no-debug-non-zts-20090626/
cd ../xdebug-XXXX/
phpize
./configure --enable-xdebug
make
# cp modules/xdebug.so /usr/lib/php/extensions/no-debug-non-zts-20090626/
# cp /etc/php.ini.default /etc/php.ini
# vi /etc/php.ini
// Hacemos los ajustes necesarios a nuestra configuración,
// importante es que las siguientes tres líneas queden dentro
// de la configuración:
extension=mssql.so
[xdebug]
zend_extension="/usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so"

Con estos pasos, ya pueden disfrutar de su instalación de PHP con xDebug y el conector de PHP para Microsoft SQL Server.

Crear una firma HTML en Mail5

unreal4u — Wed, 27 Jul 2011 16:34:22 +0000

Pequeño tip: el proceso para la creación de una firma que admita HTML en Mail5.0 es lijeramente distinto que en las versiones anteriores. En la nueva versión es:

Crear un archivo .html con lo que quisiéramos dejar de firma. Guardar en una ubicación temporal.
Abrir Preferencias en Mail y agregar una nueva firma.
Cerrar Mail
En Safari, abrir el archivo .html creado y guardarlo como un archivo tipo .webarchive
Copiar el archivo exportado por Safari a ~/Library/Mail/V2/MailData/Signatures/, teniendo cuidado en cambiarle el nombre al archivo sobreescribiendo el que ya esté. Si tienen varias firmas, primero revisen cuál es cuál, Mail5 le asigna una ID única a cada uno pero abriendo el archivo en un editor de texto, aunque verán mucha basura entremedio, igual se puede ver de cuál firma se trata.

[ACTUALIZACIÓN]
Otro tip para volver a activar el apretar una tecla y que ésta se repita es poner en la terminal el siguiente comando:
defaults write -g ApplePressAndHoldEnabled -bool false

Gracias a Rincón Apple por este dato.

[ACTUALIZACIÓN 2]
Tuve un problema con la copia de archivos: sucede que copiaba o movía y éste movimiento quedaba sin efecto alguno. La solución a este problema proviene directamente de los foros oficiales de Apple y consiste en borrar un archivo ubicado en:
rm -rf ~/Library/Preferences/com.apple.finder.plist

Solución encontrada gracias a los foros de Apple.

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í.

Nueva class publicada: Extended PGsql

unreal4u — Mon, 25 Jul 2011 04:28:16 +0000

Hice un submit de una nueva class basada en mi class ya existente para MySQL: Extended MySQLi. Hoy (bueno, más bien ayer) salió aprobada la segunda class que toma un approach algo distinto: es la misma class con los mismos métodos, pero esta vez hecho para PostGreSQL, ocupando PDO, ¿se acuerdan que hablé sobre eso hace algún tiempo?

Finalmente la class, después de mucho tiempo, vio la luz y como tal también es probable que el framework en el que estoy trabajando, realice el cambio a PostGreSQL. MySQL si bien es cierto bastante bueno, no tiene un buen sistema de transacciones, depende de muchas cosas para hacer las cosas bien y es muy fácil equivocarse, especialmente trabajando en equipo.

Sin más ni menos, les dejo el link para que puedan bajar la class Extended PGsql.

Firefox5 + IE9 y su nueva forma de redireccionar

unreal4u — Mon, 25 Jul 2011 03:45:26 +0000

Yo siempre he opinado, como desarrollador, que todos los nuevos cambios en un programa son bienvenidos, sobretodo si son buenos. Pero ocurre también que a veces estos nuevos cambios terminan siendo contra-productivos, ya que requiere una gran inversión de tiempo en acomodar lo que antes funcionaba bien y que ahora funciona mal o derechamente no funciona. A veces sólo es necesario una línea de código, pero llegar a esa conclusión puede ser una gran pérdida de tiempo.

En ese sentido, Firefox en su última versión del popular navegador, cambió la forma de tratar las redirecciones 302 y que pueden producir más de algún dolor de cabeza teniendo en cuenta lo poco difundido de esta nueva característica.

El problema surgió cuando uno de los vendedores me dijo: "No funciona la página". Debo reconocer que al principio lo ignoré debido a que los vendedores siempre dicen que no funciona la página cuando el mensaje de error desplegado al mismo dice muy claramente: "RUT inválido, por favor intente nuevamente".
Lo único malo es que esta vez, más y más vendedores me empezaron a decir lo mismo y eventualmente le empezó a pasar a los gerentes (A los dos días de hecho). Ya a estas alturas, debía haber un denominador común que hiciera que este error se produjera, así que me puse a investigar.

Una de las primeras cosas que me llamó la atención, es que en los logs empezó a aparecer el siguiente denominador común: Firefox/5.0.1. Me encantó el hecho que Mozilla actualice automáticamente sin preguntarle al usuario si desea hacerlo, pero en estos momentos estaba odiando tal característica xD.

Con eso en mente, tuve que bajar el mentado navegador (yo todavía estoy en 3.6.19 y por el momento no pienso actualizar) y empezar a probar. Finalmente logré aislar el "bug" que estaba relacionado a "algo" que tenía que ver con las sesiones y las redirecciones 302. Cuento corto: hice cientos de tests durante 1 semana (Live HTTP Headers jamás había sido tan útil), buscaba en Google por todos los términos que podrían llegar a ser y no logré encontrar la pifia. Seguía pasando en el sistema en producción pero no podía reproducir el error en menos de 10 líneas, necesario para poder reportar el problema en bugzilla.

Eso hasta que un buen día, POR FIN APARECIÓ UN POST que contenía exactamente el mismo problema y lo mejor de todo: su solución, y aquí viene lo mejor: Internet Explorer 9 tiene exactamente el mismo comportamiento!

El problema está en que la RFC 2616 #sección 10 (la que regula los códigos de estatus HTTP) dice que bajo la redirección 302 el resultado se puede o no dejar en caché. Bueno, Firefox ANTES de la versión 5, NO cacheaba la redirección 302 y ahora SÍ lo hace (tratándolo como si fuera una redirección 301), por lo tanto; y después de esta magna explicación; tenemos que la solución a este problema es simplemente enviar Pragma:no-cache y Cache-Control: no-cache antes de enviar las cabeceras de Location para que estos dos navegadores NO almacenen la redirección:

$donde = 'http://blog.unreal4u.com/';
$tipo = 302;
header('Pragma: no-cache');
header('Cache-Control: no-cache');
header('Location: '.$donde,TRUE,$tipo);

Más información en la fuente:
Fuente: InventPartners

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.

¿Qué es más rápido? ¿Procedural u OOP?

unreal4u — Tue, 07 Jun 2011 05:02:54 +0000

Una de las dudas más recurrentes y que tiene mucha antigüedad ya sea en foros o listas de correo es si es mejor ocupar procedural u OOP para programar en PHP, particularmente desde el punto de vista de uso de los recursos y la velocidad. Desde hace algunos días que venimos discutiendo eso en CHW, y pensé que sería bueno expandirme un poco más en el blog.

Lo primero que se me pasó por la mente es que cómo era posible que procedural podía ser más rápido y ocupar menos recursos que la programación orientada a objetos, que la segunda era mejor en ambientes corporativos, que el puro hecho de ser encapsulado otorgaba mejor seguridad, portabilidad y mantenabilidad, pero luego me di cuenta que una cosa no tiene nada que ver con la otra: durante la investigación que hice del tema me di cuenta que en realidad estaba mezclando los conceptos. ¿Cuál es mejor? ¿Cuáles son las ventajas y desventajas de cada una? Averíguelo haciendo click en "leer más" (o algo así).

Los datos duros:

En muy breves palabras, y casi como un resumen, les presento las ventajas y desventajas sobre cada estilo de programación:

Ventajas de Procedural sobre OOP:

Es de más rápido desarrollo en proyectos chicos
Consume menos memoria
En general, mejor para proyectos chicos

Ventajas de OOP sobre Procedural:

Es (mucho) más fácil de mantener
Es más transportable
Es encapsulado y por lo tanto, modular
Genial para proyectos grandes o en aquellos casos donde se tenga que reocupar mucho el código

Las explicaciones científicas

Durante mis investigaciones con respecto a este tema, hubo una cosa que me llamó bastante la atención: PHP con OOP va a consumir más memoria. Esto porque lo primero que se hace al hacer un include es leer todo el (o los) archivo(s), parsearlo(s) creando una copia del mismo, compilarlo(s) y finalmente ejecutarlo como un programa único. Hasta el momento ambas maneras de programación son iguales, pero la gran diferencia radica en el compilado: el motor de PHP carga muchos más archivos si el programa es OOP, ya que es prácticamente un mundo nuevo y como tal, tiene muchas más reglas y posibilidades que cubrir.

OOP de por sí implica más código (escrito) que unas funciones simples y por lo tanto, sólo por esto, el peso total se ve incrementado por este hecho. Supongamos que tenemos:

index.php -- 200bytes que realiza un include de:
hola.class.php -- 500bytes
chao.class.php -- 400bytes

En total, ese script ocupará: 1100bytes al leer las fuentes, más X-bytes adicionales al parsearlo, donde X es un número cercano a 1100. Además de esto, tiene que levantarse el server de PHP, que puede ir desde 30kbytes hasta el infinito y más allá dependiendo de qué funciones nativas estemos llamando, la complejidad de nuestro programa y otras variables desconocidas por este humilde servidor.

Explicando un poco las demás ventajas y desventajas -aunque se escapa un poco del alcance de este artículo- resulta natural que un programa programado con OOP sea más transportable que su simil en Procedural, debido a que una class es una colección de funciones, que por lo general van juntas en un solo archivo o bien son extendidas por otras. Las funciones en cambio, no se pueden llegar y sobreescribir en caso de ser necesario y tampoco ofrecen la seguridad de una class: cualquiera puede llegar y tomar una función y asignarle valores arbitrarios y de esta forma alterar el producto final. Sólo con estos dos puntos usted querido lector ya debería haberse dado cuenta de las demás diferencias, de lo contrario, busque en Google por PHP Procedural vs OOP.

¿Y el rendimiento? ¿Es más lento OOP que Procedural?

No se puede hablar de que un script sea más rápido o más lento con OOP, y si es que hubiera alguna diferencia en tiempo, sería despreciable: eso depende netamente de la mano del programador y qué hace el script: una conexión a una base de datos va a demorar ya sea bajo OOP o procedural, lo mismo corre si estamos trabajando con archivos (disco es muuuuuuucho más lento que ram).

Para contrarrestar este punto, una mucha mejor solución sería instalar algo como APC que crea una versión compilada y la deja en caché, de forma que no se tenga que parsear y compilar en cada request, con eso aumentamos la eficiencia en cerca de un 80% y se disminuye drásticamente el uso de memoria al no tener que leer y parsear, ya sea para una programación basada en OOP o en Procedural. Ya si queremos ir más allá, habrá que instalar Hip-Hop for PHP, que crea una versión en C++ de nuestra aplicación y que acelera hasta en un 50% adicional a la instalación con APC, pero esto nuevamente depende de la mano del programador y qué hace el programa, aunque sí se podría hacer notar que OOP saca una leve ventaja comparada con Procedural, ya que C++ se beneficia más de este tipo de programación (Discutible, pero es lo que he leído).

Conclusiones

Tanto uno como otro método pueden ser apropiados para nuestras necesidades, así que mi mejor consejo es: mezclen. Las cosas más generales y que más se repiten (conexión a base de datos, limpieza de consultas, etc) manéjenlas via classes y de esa forma, solucionar un bug en todas sus implementaciones se realiza de forma rápida e indolora. Además, se puede reutilizar de la forma más simple posible.
Por el otro lado, métodos relativamente simples o únicos, ármenlas de forma procedural: son de rápido desarrollo, de fácil implementación y lo más probable es que las hagan una vez en la vida y de ahí no necesite mayor mantención.