Visto que jamás iba a poder dedicarle el tiempo necesario para crear una theme en condiciones, me he decidido por utilizar una ya diseñada y he decidido utilizar esta.
Muchas gracias a Diego de Trazos web por crear la traducción al español de este theme.
Gracias a la llegada de Firefox y la aparición de la barra del google nos hemos librado de los popups. Es realmente extraño ver como un “anunciante” logra saltarse todas las protecciones y te acaba plantando su popup.
Pues bien, justo cuando esta plaga estaba remitiendo, llega una nueva forma de intromisión a través de ventanas tipo lightbox en las que nos hacen tragar la publicidad. Una publicidad que yo personalmente no veo porque enseguida trato de encontrar la “X” para que desparezca el esperpento en cuestión de mi vista.
Un ejemplo lo tenemos en El comercio digital, que premia tú voluntad de hacer click con un horrible anuncio que permanece en pantalla durante unos segundos o hasta que pulses un botón situado de forma estratégica y con un tamaño de letra lo suficientemente pequeño para que pase totalmente inadvertido.
Desgraciadamente los Popups 2.0 son muy complicados de detectar y bloquear automáticamente por lo que podemos estar ante una revitalización de la publicidad intrusiva sin solución a la vista.
Hace más de 4 años que se está discutiendo este tema y me parece increíble que se vuelvan a repetir los mismos errores.
En los últimos años FreeBSD siempre ha ido a la cola en el rendimiento de MySQL comparándolo con algunos sistemas basados en linux. La mayor diferencia entre uno y otro sistema está en la forma de tratar los threads, pero esto está a punto de cambiar gracias al esfuerzo del equipo de desarrollo de FreeBSD.
En las versiones actuales (6.2), basta con cambiar la librería de threads utilizada por MySQL para que los resultados sean muy similares a los ofrecidos por una Suse y superiores a los resultados obtenidos por un linux basado en uBuntu.
Para “obrar el milagro”, basta con agregar un mapeo de las librerías de threads para MySQL a través del archivo /etc/libmap.conf en el que tendremos que introducir estas lineas.
[mysqld]
libpthread.so.2 libthr.so.2
libpthread.so libthr.so
Para la versión 7 de FreeBSD aparecerá un nuevo scheduler (ULE 2.0) que mejorará aún mas el rendimiento de MySQL en máquinas con varias CPU y mejorará el rendimiento con respecto a linux.
Kris Kennaway ha publicado un resumen de todo lo que se nos viene encima con FreeBSD 7
Para realizar las pruebas se ha utilizado una tabla en formato MyISAM con 1753184 registros rellenados con datos aleatorios.
Ambos almacenan datos de tipo cadena, la longitud de que ocupa cada caracter suele ser de 1 byte, exceptuando las cadenas “unicode” que pueden llegar a ocupar hasta 3 bytes por caracter. El tamañó máximo para este tipo de campos es de 256 bytes. En los ejemplos me referiré siempre a letras en vez de bytes para hacer más facil su comprensión.
CHAR: Es un tipo de longitud fija, esto quiere decir que el espacio necesario para su almacenamiento es el mismo para una palabra de 5 letras que para una frase de 20.
VARCHAR: Es un campo de longitud dinámica, es decir una palabra de 5 letras, ocupará el espacio de 5 letras más un caracter de fin de cadena.
Casos de uso.
SELECT campo2 from tabla WHERE campo2 = ‘cadena’;
campo2 => VARCHAR(200) => 1,82 segundos sin indexar => 0,00 indexado
campo3 => CHAR(200) => 1,77 segundos sin indexar => 0,00 indexado
SELECT campo2 from tablal where campo2 like ‘%dena%’;
campo2 => VARCHAR(200) => 3,86 segundos sin indexar => 1,75 indexado
campo3 => CHAR(200) => 1,84 segundos sin indexar => 2,19 indexado
Después de estas pruebas, podemos concluir que CHAR se comporta mejor que VARCHAR en campos no indexados, y que VARCHAR es la mejor opción para campos que si soporten indexación.
A la hora de devolver gran número de resultados VARCHAR también se muestra superior sobre CHAR. Un SELECT con 1000000 de resultados tardó en devolver una columna de tipo char 1,24 segundos. La misma columna en formato VARCHAR tan solo tardó 1,06 segundos.
Hoy leía en el blog de Pichongol un interesante artículo sobre la cache que incorpora MySQL y el uso de Memcached para optimizar la carga de sitios web con gran carga de trabajo, pero creo que no está del todo acertado en algunos aspectos.
En su análisis sobre Sistemas intensivos en lecturas vs. Sistemas intensivos en escrituras, pasa por alto un detalle de gran importancia. Las páginas web (que es lo que nos ocupa), son sistemas en los que se acometen muchas lecturas y pocas escrituras por lo que en el 99% de los casos el uso del query cache será beneficioso. Además siempre se pueden utilizar tablas auxiliares para cierto tipo de operaciones de escritura masiva (contadores,estadísticas,sesiones, etc) y utilizar las extensiones de MySQL INSERT DELAYED y INSERT DELAYED … ON DUPLICATE UPDATE para acometer las actualizaciones en estas tablas sin influir en el tiempo de ejecución del script.
Sobre el uso de Memcached, también se pasa por alto un detalle importante, Memcached puede hacer persistir objetos en memoria para distintas máquinas a lo largo de una red y de esta forma varias máquinas se aprovechan del calculo realizado por una. Si hablamos de instalaciones de un solo servidor, el coste de las funciones serialize y unserialize reducen bastante las ventajas de utilizar Memcached.
Por mi experiencia, Memcached es especialmente productivo para entornos de balanceo de carga y funciona especialmente bien en combinación con Lighttpd+FastCGI.
Llevo utilizando PDT desde sus primeras versiones, y según me iba acomodando, también cambiaba mi forma de programar en PHP.
Antes utilizaba BBedit y ahora utilizo PDT.
Antes utilizaba programación modular y ahora programación orientada a objetos.
Sobre si es mejor la programación modular o la programación orientada a objetos, hay mucha gente más lista que yo ya ha opinado sobre ello así que lo pasaremos por alto.
Ahora bien, si al final decides que tu proyecto en concreto vas a utilizar objetos, el PDT ofrece ciertas ayudas de las que no dispone ningún otro editor de texto que yo conozca. En esta comparativa entre PDT y Zend Studio for Eclipse hay un montón de características que hacen del PDT, la mejor herramienta para la programación orientada a objetos en PHP a falta de probar a fondo el Zend Studio.
Esta transición, me ha llevado a producir un código mucho más entendible, extensible y fácil de mantener, a costa de hacer unos programas con más lentos.
De momento estoy contento con los resultados obtenidos, puesto qué tiempo de procesador me sobra mientras qué mi tiempo de programación escasea cada vez más.
Tengo varios servidores montados con Apache2.2 y en los últimos tiempos venía escuchando maravillas acerca de un nuevo navegador, Lighttpd, pequeño, sencillo y sobre todo muy rápido.
Lógicamente, antes de con un traspaso de esta magnitud decidí realizar una pequeña comparativa. Además llevaba tiempo queriendo probar las diferencias entre eAccelerator, XCache y APC así que me puse manos a la obra y estos son los resultados.
Durante los tests he ido observado como APC arrojaba mejores resultados que XCache y eAccelerator, así que para mis pruebas el mejor “opcode cache” ha sido: APC.
Solo hay una circunstancia en la que APC se ve superado por XCache ligeramente. Al tratarse de páginas sencillas con pocas necesidades de carga y utilizando Lighttpd como servidor. Si vas a utilizar Apache, APC es sin duda la mejor elección.
En cuanto a los servidores, Lighttpd es hasta 2x más rápido que Apache al servir páginas estáticas, sin embargo a medida que vamos aumentando la complejidad de la página el rendimiento de Lighttpd va decayendo hasta quedar ligeramente por debajo del rendimiendo de Apache.
Vamos a los datos…
Continúa leyendo < ?php the_title(); ?>…
Dropdown es un pequeño script basado en mootools que muestra una ventana de dialogo emergente de la parte superior de la ventana, con un efecto de fundido mediante una petición Ajax a la una dirección.
El uso es muy sencillo, basta con incluir los dos scripts y la hoja de estilos.
<script src="mootools.js" type="text/javascript" language="javascript"></script>
<script src="dropdown.js" type="text/javascript" language="javascript"></script>
<link rel="stylesheet" href="/dropdown.css" type="text/css" media="screen" />
Y luego en la página incluimos un enlace de la siguiente manera:
<a href="/ejemplos/dropdown.html" rel="dropdown">Ejemplo de dropdown</a>
Donde /ejemplos/dropdown.html es la página que queremos mostrar en el dropdown.
El uso de frameworks, ya sea ruby on rails, zend framework, Struts, Spring, etc, según mis pruebas puede provocar que una página que sin Framework se despachaba en 30 ms pase a despacharse en 300 o 400ms. Estos incrementos aunque son aceptables para una aplicación online, no lo son en absoluto para una página web de uso general y por lo tanto tenemos que decidir entre utilizar caches o no utilizar X framework.
En el caso de que hayamos decidido utilizar Zend Framework, existe una implementación que se puede realizar en cuestión de minutos, y es valida para cualquier página web. En principio, bastaría con incluir en el Bootstrap un código similar a este.
/**
* Cache
*/
require_once 'Zend/Cache.php';
$frontendOptions = array(
'lifetime' => 7200,
'debug_header' => false,
'default_options' => array(
'cache' => true,
'cache_with_get_variables' => true
),
'regexps' => array('/*' => array('cache' => true))
);
$backendOptions = array(
'cache_dir' => '/tmp/cache'
);
// getting a Zend_Cache_Frontend_Page object
$cache = Zend_Cache::factory('Page', 'File', $frontendOptions, $backendOptions);
$cache->start();
Es recomendable incluir este código al principio del BootStrap puesto que solo necesita que la ruta a la librería del Zend Framework este correctamente configurada.