Con eso aclarado, procedo entonces a las típicas dos preguntas que se me hacen con respecto a aparataje de la empresa de la manzana mordida:

¿Por qué los productos Apple son tan caros?

Sí, los productos Apple son caros, lo admito. Sin embargo, una vez que te familiarizas con el sistema y te acostumbraste a usarlo, te das cuenta que es dinero muy bien invertido, ya que hay ciertas diferencias en los Mac que son los que finalmente hacen la raya de la suma:

• Para empezar, todos los MacBook (pro y normales) cuentan con Magsafe, y en mi caso me ha salvado ya 3 veces de unas caídas que hubiesen sido de consecuencias catastróficas.
• El sistema operativo está muy bien integrado con el equipo en sí: un MacBook Pro típico viene con cámara, micrófono, teclado retroiluminado, sensores de todo tipo y Mac OS X se integra de forma perfecta con ese hardware, no hay que instalar drivers, y con suerte hay que cambiar algunos ajustes para que quede como ustedes quieran.
• Mousepad: Digan lo que me digan, lo mejor del MacBook es su mouse integrado. En mis dos primeras semanas de uso me resistí a ocuparlo debido a mi experiencia previa en los notebooks, pero al cabo de este tiempo me di cuenta que ni siquiera estaba ocupando el mouse externo. Es mucho más rápido y cómodo trabajar con el mouse integrado.
• Calidad de audio: este punto hay que separarlo en dos la verdad. Los parlantes integrados dan pena: son malos, dan muy poca potencia y suenan mal. Pero con un buen programa de audio (recomiendo Fidelia) y unos audífonos decentes (yo ocupo los Sennheiser HD515) la cosa cambia y nunca le había sacado tan buen provecho a los audífonos hasta ahora.
• El peso del equipo completo y la duración de la batería son inigualables.

En mi empresa trabajan con un software que costó X millones, ¿puedo correr esa aplicación en Mac?

Con respecto a ésta, es una pregunta difícil de contestar ya que cada usuario es distinto y si bien es cierto existen ciertas similitudes entre uno y otro, no hay que olvidar que Mac OS X está basado en Unix (que no es lo mismo que Linux) pero se adaptó a tal forma y de manera tan profunda que acabó siendo un sistema bastante cerrado. Sin embargo, con un poco de investigación y a base de prueba y error, casi cualquier programa que corra en Linux es posible correrlo en Mac, ya sea compilándolo para nuestra plataforma o mediante MacPorts.
En el caso de software escrito originalmente para Microsoft Windows la cosa es un poco distinta. A veces existen versiones de cierto software para Mac, como es el caso de Adobe, que toda su suite (Dreamweaver, Photoshop, Flash, Fireworks) es capaz de correr en Mac (y según de lo que he leído corre mejor en Mac que en Windows) y Microsoft Office, que corre bastante bien, aunque debo admitir que no soy un usuario "profesional" de esta suite, simplemente lo utilizo para escribir informes. Sin embargo, he sabido de otro software que no corre tan bien como por ejemplo Autocad, para el que prácticamente no hay alternativas.
Y si en su empresa trabajan con un ERP especial, hay grandes posibilidades de que no exista un cliente para Mac, así que ojo con eso. Si es este el caso, y siempre y cuando ese ERP no consuma una cantidad desmesurada de recursos, pueden instalar VMWare Fusion o Parallels para ejecutar Windows de forma virtualizada y de esa forma poder ejecutar ESA herramienta específica en la máquina virtualizada.

Sólo con motivos de aclaración, yo ocupo en mi tiempo de trabajo Firefox, PHP, Apache, Zend Studio, Zend Framework, Aqua Data Studio, Word y un poco de Excel, los cuales están todos disponibles de forma nativa para Mac.

Conclusión

Mac OS X es un muy buen sistema operativo a ocupar con un buen equipo como lo son los productos de Apple, pero muchas veces tampoco es la combinación ideal de acuerdo a los requerimientos del usuario. Hay ciertas cosas que no podrán hacer como por ejemplo jugar, pero a su vez el segmento al cual apunta Apple es netamente al usuario corporativo, es así como terminan siendo muy buenos compañeros de trabajo.

Otra arista que no he tocado es el precio de las licencias. Mac OS X Lion viene sólo en un paquete que vale la friolera cantidad de USD$30 (Si compran un equipo, ya viene instalado por lo que ya tendrán una licencia). Windows en cambio viene en múltiples versiones con precios que fluctúan de los USD$120 a los USD$220. Linux, dependiendo obviamente de la distro, es en mucho casos gratuito.

Otro punto que no he tocado es el tema del soporte, pero toco madera porque nunca he tenido la necesidad de llevar mi Mac a servicio técnico. Los problemas que he tenido los he resuelto yo solo y todo lo "extra" (más disco duro y mucha más RAM) lo he instalado yo solo en cosa de minutos. Sin embargo; y siempre por lo que he leído; parece que deja bastante que desear, aunque lo dejo a la duda porque por lo general uno lee más casos de frustación que de éxito.

Finalmente, sí debo decir que encuentro decepcionante la calidad de ciertas piezas, y aquí debo apuntar con el dedo al SuperDrive (nombre que Apple le designa al lector/grabador de DVD), que por lo visto es derechamente malo ya que todos coinciden en que no dura más allá de un año y medio lo cual es poco considerando la gran calidad de las demás piezas. En mi caso, el SuperDrive ya murió y con suerte me lee algunos DVDs. También he leído que el adaptador de corriente tiende a durar poco, aunque hasta el momento el mío ha funcionado bien.

A medida que iba escribiendo fui elaborando también una pequeña tabla resumen acerca de los pros y contras de los Mac, con lo cual finalizo esta nota:

Pros:

• El sistema operativo es muy estable y muy fácil de entender
• Magsafe
• Teclado retroiluminado (sólo presente en MBP)
• Mousepad
• Muy buena disipación de calor. Junto con algunos Toshiba high-end son los equipos con menores índices de reballing
• Excelente interoperabilidad con otros dispositivos Apple
• Calidad de audio (con audífonos)

Contras:

• Calidad de audio (con parlantes)
• Precio, aunque se justifica
• Poca compatibilidad con software especializado
• Algunos componentes de mala calidad (SuperDrive, parlantes, cargador (?))
• Poco soporte en caso de problemas (?)
• Pocos puertos de expansión (Sólo 2 USB en los MBP)
• Conectores propietarios.
• Muchos programas externos son pagados

Si sientes que algo le faltó al artículo, coméntalo en los comentarios y con gusto lo agregaré a este post.

Así que ya saben, si no funciona:
<base href="/hola/chao/" />
Deben poner:
<base href="http://unreal4u.com/hola/chao/" />

Para que Internet Explorer la tome en cuenta.

¿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 <a>), 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:

<!DOCTYPE html>
<html><head>
	<title>Testing prefetch with HTML5</title>
	<script type="text/javascript" src="../jquery.min.js"></script>
	<link rel="prefetch"  href="prefetch.php">
	<link rel="prerender" href="prefetch.php">
</head><body>
<a href="prefetch.php" class="prefetch">Please click here to display the (prefetched) page</a><br />

<input type="button" id="buttonContents" value="Get contents" />
<div id="contents"></div>
<script type="text/javascript">
$('#buttonContents').click(function(){
	$.ajax({
		url:'prefetch.php',
		success:function(data){
			$('#contents').html(data);
		}
	});
});
</script>
</body></html>

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){
            $("<link />", {
                rel: "prefetch", href: Element
            }).appendTo('head');
            $('<link />', {
                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!

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:

<html><head><title>Proyectos en unreal4u</title></head><body>
<h1>Proyectos</h1>
<p>Edit .index for index options</p><ul><?php
$aliasFile = explode("\n",file_get_contents('.index'));
foreach($aliasFile AS $aliasString) {
	$aliasFileTmp = explode('|',$aliasString);
	if (!empty($aliasFileTmp[1]) AND substr($aliasFileTmp[1],0,1) != '#') {
		$aliasFileCompleted[$aliasFileTmp[0]] = $aliasFileTmp[1];
	}
}

$itemHandler = opendir('.');
$output = '';
while (($item = readdir($itemHandler)) !== false) {
	if (substr($item,0,1) != '.' AND is_dir($item)) {
		$linkText = $item;
		if (!empty($aliasFileCompleted[$item])) $linkText = $aliasFileCompleted[$item];

		if ($linkText != '.') {
			$output .= '<li><a href="'.$item.'">'.$linkText.'</a></li>';
		}
	}
}
echo $output;
?></ul></body></html>

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.

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

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

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

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.

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