Ahora hay noticias de lo que será la versión 9, con la cual parece que Microsoft al fin logrará ponerse a la par del resto de navegadores. Y si, Microsoft también quiere participar del hype del HTML5.

Esta es la primera previa del IE9, la en la cual ya prometen:

• Video basado en HTML5 (<video>) usando el codec h.264, el mismo que usan Safari, Chrome y Opera.
• Audio basado en HTML5 (<audio>) usando los codecs de MP3 y ACC.
• Imágenes vectoriales basadas en SVG, con lo cual quienes odian a Flash y piden a gritos su muerte, ya se podrán hacer animaciones.
• Aceleración de video 2D para el renderizado CSS/Texto y SVG usando DirectX, por lo que parte de estas animaciones irían hacia el GPU, reduciendo la carga en el CPU.
• Mejoras en el motor de Javascript, incluso en esta previa debería estar a una velocidad similar que Firefox 3.6 según los tests de SunSpider. Según Microsoft el motor de Javascript corre en un hilo (thread) aparte del navegador, si tienen un procesador de varios núcleos debería funcionar mejor. Pueden ver más detalles de esto en el sitio de pruebas de IE9.
  
• Soporte a todos los selectores CSS3, incluso con esta primera previa todos deberían funcionar. También han agregado soporte a los bordes y fondos de CSS3 y varios niveles del DOM; solo hay que aclarar que Microsoft se basa estrictamente en la W3C, mientras que otros navegadores los han ido incluyendo usando su propia especificación (ej. -moz-border-radius en lugar de border-radius), por eso los datos de Microsoft son algo incorrectos.

Bastantes novedades, ¿Pero qué tanto ha mejorado? Si usamos la prueba ACID3 como referencia:

IE9 llega a 55/100. Sabiendo que Chrome, Safari, Opera y Firefox llegan al puntaje 100/100 (o casi) pareciera que falta aún por mejorar. Si tomamos en cuenta que IE8 apenas marcaba 20/100 en dicho test, deberíamos tener un poco de esperanzas que la versión final de IE9 no quedará tan mal.

De nuevo, esta apenas es una primera vista del motor IE9 y que ya pueden probarlo en su PC, aunque no esperen tener un navegador funcional por ahora.

Honestamente IE9 luce bastante bien para quienes nos dedicamos a desarrollo web, el solo tener un mejor rendimiento de JavaScript y mejor soporte CSS y DOM ya nos ahorra dolores de cabeza. Quizás esta sea la versión en la que finalmente Microsoft se pueda reivindicarse y hacer que nos olvidemos de sus pasadas versiones… quizás.

Vale aclarar que IE9 solo va a correr en Windows 7 y Windows Vista, quienes aún usan Windows XP quedan fuera.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Supongamos que tenemos la categoría “minipost” y que el ID de esta es el 19, y queremos que los posts de esta categoría no salgan en la portada y el feed principal del blog; Dependiendo de como se categorizen los posts del blog, la categoría “miniposts” podría ser una “sección aparte” del sitio.

Para esto solo necesitamos agregar un pequeño plugin:

<?php
/*
Plugin Name: Excluir categorías
Plugin URI: http://www.maestrosdelweb.com
Description: Excluir categoriías de la portada de WordPress
Version: 0.2
Author: Javier Aroche
Author URI: http://www.maestrosdelweb.com
*/

function exclude_cat($query)
{
	if ( $query->is_home || ($query->is_feed && $query->query_vars['category_name']=='') ) {
		$query->set('cat','-19');
	}
return $query;
}
add_filter('pre_get_posts','exclude_cat');

Toda la exclusión funciona gracias a $query->set('cat','-19'); . Los valores negativos significan exclusión y los positivos, obviamente para incluir categorías. Esto se ejecutará cuando se está en la portada o en el feed de la portada.

Si quisiéramos excluir varias categorías, basta con separarlas por comas:

$query->set('cat','-19,-3,-26');

También se pueden se pueden excluir de otras secciones del blog, digamos que en la categoría “Internet” tampoco se muestren los posts de “minipost” (o bien podrían no agregar la categoría Internet en primer lugar ).

Solo una aclaración sobre esto: WordPress tiene un bug al excluir posts entre categorías, ya lo había reportado hace tiempo; si quieren usar esta opción solo apliquen el parche que subí en el reporte del bug. El parche solo es necesario para excluir posts de una categoría (X), cuando se ven los de otra categoría (Y).

Una vez parchado WP, hay que agregar una condición más antes del return $query; :

if ( $query->is_category && $query->query_vars['category_name']!='minipost') {
	$query->set('cat','-19');
}

El valor de $query->query_vars['category_name'] es el category slug.

Y así todos los posts de “minipost” quedan fuera del sitio, excepto cuando se visita la página de esta categoría (/category/minipost/) y el feed de esta. Esto es útil cuando se están mostrando en el sidebar del sitio usando get_posts(), no tendría sentido mostrarlos dos veces

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Un detalle de Google Buzz, a pesar de que está pensado para compartir cosas, no es intuitivo saber como agregar sitios/feeds para que se publiquen automáticamente dentro de tu cuenta.

Para agregar nuevos sitios a Google Buzz, este depende del Social Graph API para descubrir nuevos sitios relacionados a tu cuenta. La idea detrás de esta dependencia es que solo el propietario del sitio pueda publicar sus contenidos en Buzz. Esto se demuestra usando el XHTML Friends Network (XFN), que es un microformato para expresar relaciones entre sitios.

La primera cosa que hay que hacer editar nuestro perfil en Google y agregar el sitio que queramos en Buzz. Asegúrate de marcar el checkbox de que dicho sitio está relacionado contigo:

Ahora para completar la relación con Social Graph, hay que agregar un enlace hacia tu perfil de Google, desde el los sitios que acabas de agregar:

<a rel="me" href="http://www.google.com/profiles/jaroche" rel="me" >Perfil en Google</a>

Noten la parte del rel=”me”, según el XFN indica que dicho enlace va a otro sitio tuyo. Si ya usas el widget de enlaces de Wordpress, este ya incluye soporte de XFN. Si lo que quieres es solo validar respecto al Social Graph API, pero sin que se muestre el enlace en la página, puedes agregar esto dentro del <head> del sitio:

<link rel="me" type="text/html" href="http://www.google.com/profiles/jaroche"/>

Ahora a comprobar que todo esté bien, usaremos el Recrawl Tool de Social Graph para agilizar las cosas. Esta herramienta nos ayudará a comprobar que los sitios relacionados con nosotros enlacen de vuelta al perfil de google:

Si ya logramos que salga comprobada la relación, será cuestión de horas para que este sitio aparezca disponible entre los sitios conectados en Google Buzz. Ponen en cuenta que una vez conectado el sitio en Buzz, se publicará el contenido completo y hasta diría que es un poco difícil visitar el sitio original.

Para sitios con varios autores

Para los sitios con múltiples autores con Wordpress, hice un pequeño plugin para que cada uno pueda validar su página de autor dentro del blog (por ejemplo en nuestro caso: /autores/jaroche/).

function profilelink()
{
	global $wp_query;

	if ( !$wp_query->is_author ) return;

	$author = $wp_query->get_queried_object();
	$gtalk = get_the_author_meta( 'jabber', $author->ID );
	if ( !empty($gtalk) ) {
		$parts = explode( '@', $gtalk, 2);

		if ( isset( $parts[0] ) ): ?>
		<link rel="me" type="text/html" href="http://www.google.com/profiles/<?=esc_attr($parts[0])?>"/>
		<? endif;
	}
}

add_action('wp_head', 'profilelink' );

Todo lo que necesita hacer el autor es llenar el campo Jabber/Gtalk dentro de Wordpress, puede ser solo el nombre de usuario o con el “@gmail.com”. Pueden descargar el plugin desde acá.

El único problema que tiene esto con Buzz, es que este está tomando el feed general del sitio, no el de solo el autor, por lo que todas las entradas publicadas en el sitio saldrán también en su Buzz. Si alguien sabe como indicarle a Buzz que feed usar, se lo agradeceré

PD: Mi perfil de google está por acá.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

¿Qué necesito para limpiar mi computadora?

En el caso de una computadora de escritorio solo necesitaras un destornillador, una aspiradora para soplar aire, una brocha/pincel, seguir algunos consejos básicos de mantenimiento y un poco de sentido común.

Probablemente deberías sacar el gabinete a un espacio abierto, por si este lleva muchos meses sin ser limpiado; procura enfocarte en el enfriador del CPU, la fuente de poder y cualquier otro componente que tenga un ventilador, allí es donde se acumula la mayoría del polvo y donde puede afectar más fácilmente, usa la bronca para quitar el polvo más resistente.

En el caso de una laptop deberías limpiar solo el exterior de esta; tampoco uses una aspiradora o compresor de aire, ya que las teclas de esta podrían dañarse o desprenderse. Hay buenas guías que te explican como limpiar el teclado de una laptop y sus demás componentes. Si crees que tiene mucho polvo por dentro o sus ventiladores ya hacen ruido, puedes llevarla a un centro de servicio para que le hagan el mantenimiento de limpieza adecuado.

También puedes usar algún tipo de jabón líquido o siliconas, aplícalos primero en un paño y luego usa este para limpiar tu computadora o laptop; procura que el líquido no sea demasiado y que se filtre hacia los componentes internos del PC. No uses productos que puedan dañar los plásticos de tu PC, para limpiar muchas de las suciedades probablemente solo falte un poco de agua y paciencia.

¿Qué puedo hacer para que se ensucie menos?

Primero que todo, limpiarla regularmente no permitas que tenga una capa de polvo.

Si el gabinete de computadora está sobre el piso, prueba ponerla sobre el escritorio o al menos un poco más alto que el suelo; eso evitará que mucho del polvo que hay en el suelo llegue a esta. Apaga la computadora cuando estén haciendo la limpieza en la habitación donde está ubicada, el polvo que se sacude queda en el aire y llegar en mayor cantidad a la computadora por los ventiladores de esta.

No comas cerca de tu computadora, esto evitará que los restos de comida lleguen al teclado y mouse. Se cuidadoso con la bebidas y más si estas trabajando cerca de una laptop, una buena dosis de Coca Cola la puede mandar al otro mundo.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Otra ventaja de agregar esto al feed, es que quienes publican nuestros contenidos tomados del feed (scrapping) en otros sitios, este crédito también saldrá en sus sitios enlazando al nuestro de vuelta y dejando en claro de donde viene el contenido.

Esto es un sencillo plugin para Wordpress, similar al Ozh Better Feed y sin tantas opciones como este, pero sin hacer una consulta adicional extra a la base de datos; me gustan más los plugins que agreguen la menor carga posible

Algo adicional que agregué a este plugin fue la opción de mostrar el avatar del autor, si ya están usando el plugin de Author Image usará los avatars de este, sino se usará Gravatar o en ultimo caso se mostrará la imagen predeterminada que ustedes definan.

function rss_extracredit($content) {
	if(!is_feed()) return $content;

	$avatar = str_replace( ' />' , ' style="float:left;padding:0 5px" />', get_author_avatar() );

	$author = get_the_author();
	$permalink = get_permalink();

	$content .= "<hr /><p>$avatar <strong>$author</strong> para <a href=\"" . get_bloginfo('url'). '">'.get_bloginfo('name'). '.<br />'
	."<a href=\"$permalink#respond\">Agrega tu comentario</a> | <a href=\"$permalink\">Enlace permanente</a> al artículo</p>";

	return $content;
}

add_filter('the_content', 'rss_extracredit');

El plugin solo agrega este crédito al feed, pero si comentan la parte de:

if(!is_feed()) return $content;

También lo agregará al sitio.

Les dejo el plugin (con licencia GPL 2) para que lo descarguen o bien pueden ver el código fuente en github. Si lo instalan, solo falta definir una imagen predeterminar para cuando no se encuentra un avatar. Debería funcionar sin problemas, sino dejen un comentario por acá

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

La forma tradicional: según la dirección IP

De hecho, hasta hace un tiempo esta era la única forma de saber la procedencia de un visitante: tomar la dirección IP (pública) desde la cual recibimos la petición y compararla con una base de datos de IPs con sus posibles localizaciones. Para determinar la IP desde la cual nos visita el usuario, desde de php sería:

$ip = isset($_SERVER['HTTP_X_FORWARDED_FOR'])
    ? $_SERVER['HTTP_X_FORWARDED_FOR']
    : $_SERVER['REMOTE_ADDR'];

Esta ip no representa el nodo real desde el cual nos visitan, pero usualmente es una buena aproximación del origen del usuario.

Existen varias bases de datos dedicadas a recopilar este tipo de información, quizás la más popular sea la versión gratuita de IPligence (mientras no se use para fines comerciales y se les dé el crédito). Esta versión incluye 150,000 referencias por país, Microsiervos hizo un experimento en el que determinaron que es 95% exacta.

Hay que tener en cuenta que IPligence te da su base de datos en formato CSV y con las IP’s convertidas a número enteros, pero ellos explican como hacer la conversión de IPs y como cargar estos datos hacia un gestor de base de datos.

Otra opción son los datos de Hostip, un proyecto abierto que con ayuda de la comunidad y algunos ISPs ha ido recolectando sus datos. Puedes descargar la base de datos de IP’s, o usar su API incluso.

Deja que el mismo usuario te diga con HTML5

Una de las nuevas funcionalidades de HTML5, es la posibilidad de saber la ubicación del usuario (una vez este lo autorice). Obviamente los navegadores aún tienen que implementar la especificación de Geolocalización del W3C, que hasta el momento Firefox 3.5, el iPhone OS, Android y Google Chrome, entre otros, ya ofrecen esta opción.

Si nos basamos en la especificación del W3C, para detectar la ubicación del usuario es bastante sencillo:

if (typeof navigator.geolocation == 'object'){
    navigator.geolocation.getCurrentPosition(mostrar_ubicacion);
}

function mostrar_ubicacion(p)
{
    alert('posición: '+p.coords.latitude+','+p.coords.longitude );
}

La exactitud dependerá del agente con el cual se intente detectar la ubicación, los móviles que cuentan con GPS obviamente serán mucho más exactos que si se usan las redes WIFI cercanas para adivinar la ubicación.

Tal vez convenga usar geo-location-javascript, un framework que agrupa varias propuestas de Geolocalización (aparte de la del W3C) en un solo lugar. Usarlo es igual de sencillo:

if(geo_position_js.init()){
   geo_position_js.getCurrentPosition(success_callback,error_callback);
}
else{
   alert("Functionality not available");
}

function success_callback() {...}
function error_callback() {...}

Hice un pequeño ejemplo usando este framework para que lo prueben en su navegador. Para ver como funciona, solo vean el código fuente o bien pueden bajarlo desde github

Base de datos de IP’s vs HTML5

Usar una base de datos de IP’s tiene la ventaja que todo funciona detrás, el usuario no debe autorizar el compartir su ubicación ni debe usar un navegador moderno; lo malo que estos datos son precisos solo a nivel de país y si el hardware del usuario ya cuenta con un GPS no lo estamos aprovechando. Dependiendo de lo que queramos hacer, probablemente el mejor enfoque sea usar una base de datos de IP’s sencilla y a la vez preguntarle al usuario que nos comparta su ubicación.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Después de todo, para mantener backups todo lo que se necesita son las herramientas apropiadas y principalmente la disciplina de crearlos constantemente; si crees que eres incapaz de tener tal responsabilidad, buscar algún programa o haz un script que se encargue por ti de general puntualmente los respaldos de tus archivos/sitios/bases de datos… a menos que quieras que te suceda lo mismo que a Ma.gnolia a inicios de este año.

Pero hay que tener algo claro: una cosa es tener backups y otra haberse recuperado a partir de estos; hay que estar seguros que realmente podamos recuperar toda (o casi) nuestra información, no solo los datos sino también configuraciones, compilaciones de los programas y metadata de la cual dependamos.

¿Alguna vez has hecho la simulación de recuperar tus datos a partir de tus backups? ¿Tienes una copia en otro Datacenter? ¿Sabes cuanto tiempo tardarás en tener todo de vuelta? ¿Estás seguro que si falla el disco duro del servidor, puedes recuperar todo? Todo esto viene a que Jeff Atwood, de Coding Horror, recientemente tuvo un problema con su servidor y de pronto casi había perdido todo sitio, por confiar los respaldos su información a terceros.

No es la primera vez que hablamos de backups, herramientas y sitios relacionados acá en Maestros del Web:

• Es viernes! qué tal si haces un respaldo de información
• ¿Cuándo hiciste el último respaldo de tu información?
• Programas y servicios para hacer respaldo de tu información

De hecho mientras escribía este artículo, hice una copia completa de los sitios que administro, incluyendo:

• Un .tar de los archivos de cada sitio.
• Un sqldump de cada base de datos.
• Copias de los httpd.conf, my.conf, php.ini y otros archivos relacionados con la configuración del servidor
• Estas copias quedan en el disco secundario del servidor.
• Aparte, todo esto lo envíe a Amazon S3, desde cada servidor. Cada cierto tiempo bajo una de las copias que están en S3 hacia mi máquina local.
• Sumado a la copia diaria de los sitios que CPanel genera.

Todo esto lo hago con la ayuda de un script basado en los comandos que toda distribución GNU/Linux incluye, para enviar archivos hacia S3 desde el servidor lo hago con S3Sync.

En el caso de mi Desktop, aunque la mayoría de datos ya están en la nube, trato de mantener al día mis respaldos hacia un disco duro externo y uso JungleDisk para enviar lo más importante hacia S3

… ¿Y si de pronto nuestros servidores/datacenter mueren?

En el tiempo que tengo administrando sitios, ya he pasado por experiencias en las que debemos levantar una copia completa del sitio en otro servidor, y mientras menos tiempo pase abajo mejor. Idealmente tendríamos una infraestructura de respaldo capaz de manejar todo el tráfico del sitio, y que se mantengan sincronizados respecto a nuestros backups, minimizando el tiempo que el sitio pasaría fuera de linea.

Otra idea, sería provechar el Cloud hosting, Amazon EC2 por ejemplo, mantener imágenes listas con las cuales podamos iniciar instancias y levantar nuestra infraestructura en la nube; pero con la ventaja que si no la usamos, pagaríamos un precio mucho menor que tener un servidor dedicado sin uso.

En fin, si aún no tienen backups completos de su información, háganlos ya mismo. Si ya los tienen, hagan una prueba para recuperarse a partir de estos. ¿Cuanto tiempo pueden perder? Seguro mucho menos que empezar a rescatar las cenizas en caso de desastre. Todo es cuestión de disciplina

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Google Public DNS es como cualquier otro servicio de DNS’s, pero enfocado al mejor rendimiento, seguridad y con el respaldo de un gigante como Google; algo contra lo que los Proveedores de Internet es difícil competir (sabiendo que muchos ni se preocupan mucho por sus servidores DNS).

Para utilizar Google Public DNS basta con configurar el sistema para que utilice estas IPs (y hay que aceptarlo, bastante fáciles de memorizar):

• 8.8.8.8
• 8.8.4.4

Este nuevo servicio de Google no es el primero en su tipo, ya habíamos mencionado a OpenDNS, al cual en lo personal lo encuentro muy útil. Entre OpenDNS y Google Public DNS puedo destacar algunas diferencias:

• OpenDNS ofrece más controles y estadísticas sobre su servicio (al crear una cuenta con ellos), brinda la posibilidad de filtrar/bloquear dominios por categoría o especificar cuales. Algo interesante para empresas y familias. Google Public DNS solo resuelve nombres de dominio y ya, sin controles ni estadísticas.
• OpenDNS debe ganar dinero de alguna parte, no tiene el capital de Google, es por eso que interceptan la resolución de dominios no existentes para mostrar anuncios, de hecho Google critica este comportamiento y garantiza que ellos no lo harán. De todas formas esto se puede desactivar.
• OpenDNS también ofrece un servicio de pago enfocado a empresas, con SLA y algunas opciones extras. Google Public DNS de momento no cuenta con ningún tipo de servicio especial

Para los conspiracionistas y los que prefieren mantener su alma lejos de La Nube, este sería otro punto más por donde Google estaría recolectando datos y comportamientos de los usuarios y sitios que visitan (y que el fundador de OpenDNS no tardó en insinuar). Google aclara que ciertos datos (no personales) solo se usarán para análisis internos y mejoras a la infraestructura de su servicio. Queda en cada quién creerles o no

Vale aclarar que OpenDNS y Google Public DNS solo resuelven nombres de dominio, no son servicios para hospedar la zona de un dominio en particular, para eso hay otras opciones.

En fin, si me preguntan yo seguiré usando OpenDNS ya que si estoy utilizando los filtros de dominios; pero aún así Google Public DNS parece una buena alternativa para quienes están detrás de un DNS lento o que tarda demasiado en actualizar los cambios en los registros de los dominios.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Es interesante presenciar como evoluciona una idea, pasando desde el plan de negocio hasta algo del código; apreciar la sinergia que surge al juntar personas con diferentes especialidades, pero con el interés de aprender a como hacer rentable una idea. Pero quizás más importante que eso, fue hacer contactos, ya que después de todo Internet es un pueblito. Nunca sabes cuando te podrían servir

Me gustó bastante los comentarios de quienes llegaron como mentores a este iWeekend:

• Justin Wright de KickStart.
• Cesar Salazar.
• Raúl Ramírez, mejor conocido por escribir en Isopixel.
• Gustavo Arezpe.
• Artugo Garrido, creador de Twitea.me.

El proyecto elegido en este iWeekend fue Mapatlan, idea para colocar historias en un mapa similar a Wikimapia, pero enfocado más a historias que a lugares. Para Tania Castillo, la emprendedora detrás de este proyecto, se lleva una buena dirección para este y muchas ideas de como seguir adelante. Esperamos pronto saber más de como ha evolucionado este proyecto, y aún mejor si sabemos que el resto de proyectos presentados en este iWeekend logran concretar algo.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Aún cuando sigue siendo el mismo modelo de las ediciones anteriores de otros países, no es lo mismo verla de lejos que vivirla.

Tener presencia en una Campus Party es bastante agitado: Debes prepararte para largas filas de personas (en el primer y último día), estar pendiente de la agenda y los cambios en esta, los 4Gbps del enlace a Internet en la Campus, garantizan que casi cualquier lista de cosas por descargar se termine; y hay mucha gente con la cual puedes compartir y socializar físicamente.

El ambiente de la Campus

Una de las cosas que más me agradó fue el ambiente de la Campus Party, saber que podías dejar tus cosas en tu puesto para atender alguna charla, y saber que al regresar allí estarían. Ese aire de respeto muto (salvo algunas excepciones), porque que al final de cuentas todos estábamos lejos de casa.

Yo tuve le gusto de saludar a viejos amigos que he conocido en eventos anteriores, conocer a algunas estrellas en twitter, e hice mi esfuerzo por charlar con tantas personas como me fue posible. Fue algo irónico que al tener un excelente enlace a Internet, la mayor parte del tiempo la pase alejado de mi netbook.

Las charlas y exposiciones

En las charlas hubieron de todos niveles, por mi parte aproveché para aprender más de Overclocking y Astronomía, para no seguir escuchando de los mismos temas de siempre . Vale notar que el área de Cultura Digital fue la que más charlas tuvo y la que más audiencia llego a tener. Definitivamente oportunidades para documentarse en una nueva área no faltaron, y por lo que vi muchas personas las aprovecharon. Campus Party no solo fue un lugar de ocio con una super conexión, sino también un evento educativo.

Por otra parte el área de Campus Experience fue muy interesante, presentando algunas ideas de realidad virtual, automatización e interfaces alternativas. Mi favorita fue definitivamente la del “Laberinto en el cubo”:

Si por alguna razón no pudieron asistir al Campus Party de México, puede revisar las fotos oficiales en flickr, el tag “campuspartymx” y los videos en youtube… al menos para darse una idea de lo que fue.

Esta es la segunda vez que visito México y me llevo una buena impresión de este país y de la calidez de su gente. Fue curioso encontrarme con otros mexicanos que visitaban por primera vez el Distrito Federal, vaya enorme ciudad. Aún seguiré algunos días por acá conociendo un poco más de México.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

El problema principal que soluciona esta actualización tiene que ver con los trackbacks y un ataque especial que puede afectar a cualquier blog que una versión anterior a Wordpress 2.8.5. El ataque está explicado a detalle en Desvaríos informáticos (y en mi opinión un tanto exagerado sobre el impacto en la seguridad). Dicho ataque tiene que ver con la función mb_convert_encoding() y de como Wordpress maneja los valores de entrada. Este es el código en donde se utiliza mb_conver_encoding():

if ( function_exists(’mb_convert_encoding’) ) { // For international trackbacks
   $title     = mb_convert_encoding($title, get_option(’blog_charset’), $charset);
   $excerpt   = mb_convert_encoding($excerpt, get_option(’blog_charset’), $charset);
   $blog_name = mb_convert_encoding($blog_name, get_option(’blog_charset’), $charset);
}

El valor de $charset viene de $_POST['charset'] y contiene los juegos de caracteres (separador por coma) que posiblemente se hayan usado en los textos de la petición; no se controla su valor ni le limita su tamaño. El problema viene a ser cuando se utiliza como argumento en mb_convert_encoding(), si se envía una petición donde $title y $charset sean absurdamente grandes (350KB según el ejemplo en Desvaríos informáticos), mb_convert_encoding() haría demasiadas comprobaciones, tomando hasta varios minutos por cada petición.

El impacto obviamente depende de la configuración del servidor y las capacidades de este, pero como la mayoría no tenemos un servidor dedicado, nos dejarán con el servidor atascado. La solución a este problema consiste en limitar $charset para que solo permita indicar un juego de caracteres (al eliminar las comas):

$charset = str_replace( array(',', ' '), '', strtoupper( trim($charset) ) );

Solo queda el caso de si $_POST['charset'] fue definido como un Array (y que Wordpress no lo soluciona explícitamente) ya que mb_convert_encoding() también permite definir la lista de juegos de caracteres de esta forma. Por si acaso, modifiqué el parche de Wordpres incluyendo:

$charset = (string) $_POST['charset'];

Con eso debería cerrarse la puerta a problemas por esa parte. Wordpress 2.8.5 soluciona otros problemas menores que nunca dejan de aparecer, pueden ver la lista completa de cambios y bajar solo los archivos modificados desde Wordpress 2.8.4

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Cuando un servidor web ya no puede mantener todas las peticiones de un sitio por si solo, una buena forma de aliviar la carga en este, es utilizar un (sub)dominio adicional en un servidor aparte. En este vamos a hospedar todo el contenido estático, como:

• Archivos relacionados a la plantilla: imágenes, archivos de javascript y hojas de estilos
• Imágenes usadas para complementar el contenido, dependiendo del Gestor de contenidos este podría automatizar el proceso de subida hacia el otro servidor
• Archivos complementarios como PDF’s, MP3’s, Videos o cualquier otro archivo que no sea generado dinámicamente

La idea es contar con un segundo servidor que utilice muy pocos recursos y que responda con los encabezados (headers) apropiados para que cada cliente mantenga estos archivos en su caché local. Al hacer esto, podemos reconocer algunas ventajas:

Balanceo de carga

Obviamente la primer meta de contar con un servidor adicional para contenido estático, es quitar carga del servidor principal, encargado de generar las páginas de nuestro sitio. Este otro servidor puede ser un más sencillo que el principal, si lo configuramos para utilizar Worker o algún servidor web alternativo como Lighttp, NGnix, etc.

Para lograr este “balanceo de carga” es tan fácil como modificar el código generado para que se enlacen a los archivos en el dominio alternativo. Por ejemplo, en Foros del Web utilizamos el subdominio static.forosdelweb.com, Yahoo usa el dominio yimg.com, La familia de sitios de Stack Overflow usan sstatic.net.

Por supuesto al llegar a tener un tráfico mucho mayor se llegará a necesitar un balanceo de carga real, con un proxy en frente de los servidores web, y mover el contenido estático a un CDN profesional como Amazon S3/CloudFront o similares.

Libre de cookies

Cuando enviamos una cookie al usuario, su navegador nos la enviará junto a todas las peticiones, sean páginas o imágenes. Esto es un problema, ya que hará que las peticiones/paquetes sufran mayor fragmentación. Yahoo hizo un estudio sobre el impacto del tamaño las cookies y el incremento en el tiempo de respuesta del servidor, de alli se concluye que es mejor reducir al mínimo posible el tamaño (si usas un CMS esto es complicado), o aún mejor que los recursos que no necesiten de estas estén en un dominio aparte, libre de cookies.

Descargas paralelas

La especificación del HTTP/1.1 sugiere que cada navegador limite el número de descargas simultaneas a 2, para un mismo host. Si tenemos un dominio adicional, esto debería darnos otras 2 descargas paralelas adicionales, reduciendo el tiempo necesario para cargar el sitio. Tampoco significa que debemos agregar varios subdominios con tal de tener muchas descargas paralelas, el incremento en consultas DNS y uso del conexiones adicionales degrada la ventaja de que se hagan en paralelo.

¿Desventajas?

No puedo pensar en desventajas reales de usar un dominio para contenido estático, más que:

• Que los ingresos y el tráfico del sitio no justifiquen el gasto en un servidor adicional o en pagar los gastos de usar Amazon S3.
• Tener un servidor adicional que no soporte la carga del contenido estático, haciendo que el tiempo de carga del sitio sea mayor.
• Que el gestor de contenidos por alguna razón dificulte, o no se tenga el conocimiento para hacer que ciertos recursos se enlacen al otro dominio.

¿Alguna otra ventaja o desventaja? ¿Experiencias al respecto? Dejen nos un comentario

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Multiproceso tipo Prefork

• Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
• Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
• Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
• Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
• Prefork es la configuración predeterminada en la mayoría de instalaciones.

Multiproceso tipo Worker

• Apache inicia varios subprocesos y estos a su vez mantienen varios hilos (threads) con los cuales procesaran las peticiones. Un subproceso proceso puede atender a varios clientes a la vez, según se indique en ThreadsPerChild.
• El hecho de que un subproceso pueda manejar varias peticiones a la vez, hace que se requieran menos recursos para atender a cierto número de peticiones simultaneas.
• El inconveniente de Worker está en que requiere que todos los módulos/extensiones que se vayan a usar sean Thread-Safe, limitando el tipo de procesamiento que se puede llevar a cabo con el servidor web.
• Un fallo crítico (que el subproceso termine repentinamente) afecta a varias peticiones, por eso se requiere que se cumpla el Thread-Safe.
• Ya que no se pueden usar aceleradores de PHP junto a Worker, el uso intensivo de este debería ser evitado con algún tipo de sistema de caché adicional (si fuera Wordpress usaría WP-Cache).
• Worker puede ser una buena solución para un servidor de contenido estático.
• Worker solo está disponible desde Apache 2.x .

Prefork vrs Worker

Para darles una idea de la diferencia en el consumo de recursos entre Prefork y Worker, los he utilizado en las siguientes condiciones:

• Prefork en un servidor bastante poderoso (8 núcleos y 4GB de RAM), manejando casi solo contenido generado desde PHP y con XCache instalado. El contenido estático se sirve desde otro servidor.
• Worker en un servidor sencillo (2 núcleos y 4GB RAM), más que todo contenido estático. La mayoría del contenido generado con PHP queda almacenado en cachés (siendo a la larga contenido estático).

Carga promedio del servidor configurado con Prefork:

Carga promedio del servidor configurado con Worker:

• El servidor de 8 núcleos (Prefork) promedia una carga del servidor mucho más alta, que el servidor de 2 núcleos (Worker).
• Si hablamos solamente las peticiones simultaneas que cada uno puede manejar, el servidor con Worker puede manejar casi el doble que el servidor con Prefork, y aún con una carga en el servidor más baja. Manejaría muchas más antes de que el servidor llegue a su límite. Para que Prefork llegue a estos niveles, tendríamos que lidear con el ServerLimit (que en CentOS significa modificar el código de Apache) y apostar por más memoria RAM.
• Obviamente la aplicación en el servidor con Prefork utiliza mucho más CPU, si modificáramos el servidor web para que use Worker, la misma aplicación tendría un menor rendimiento (no se puede usar un acelerador de php, recuerden).

Si me preguntan, yo preferiría hacer la aplicación más compatible con Worker (agregar un sistema de caché) que usar el servidor con Prefork, un servidor sencillo puede escalar mucho mejor. Si el contenido es muy dinámico (invalidar el caché resulta muy costoso) enviaría todo el contenido estático a otro servidor (con worker) para que solo atienda el contenido dinámico.

¿Por qué Prefork o Worker, y no FastCGI?

Hablamos de Prefork y de Worker porque en todos los servidores (dedicados) que tengan instalado WHM/Cpanel se puede hacer el cambio entre estos siguiendo los pasos de EasyApache, aún sin CPanel instalado es bastante sencillo hacer el cambio ya que solo significaría modificar la configuración, si se usan módulos compartidos, o recompilar si se manejaron como módulos estáticos. Comodidad más que todo.

Una diferencia importante entre Prefork/Worker y CGI/FastCGI, es que en los primeros PHP corre como un módulo de Apache, mientras que en FastCGI corre como un proceso (o grupo de) separado de Apache. Hechar a andar esta configuración puede ser bastante retador (y que mi experiencia con FastCGI es menor).

Si quieren leer mucho más de como aplicar esto en sus servidores, les recomiendo repasar la documentación oficial de Worker y Prefork, aprender como modificar la configuración de Apache (httpd.conf), saber como cambiar entre ambos modos (recompilar o editar la configuración), y claro experimentar

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Desde su creación, hace 11 años, a un acuerdo con el Gobierno de Estados Unidos, concretamente con el Departamento de Comercio, con el cual podían ejercer cierto control sobre las decisiones de la ICANN. Dicho acuerdo generó muchos años de críticas sobre porque una organización como la ICANN (y a la larga, Internet) estaba ligada a un Gobierno en particular.

A partir del 1 de Octubre dicho acuerdo deja de estar vigente, y la ICANN pasa a ser una entidad global y privada sin fines de lucro. Esto tampoco significa que puedan hacer lo que quieran, pero sin duda quita un peso en las políticas internacionales del manejo y el futuro de Internet.

Para los que estamos en el «nivel más bajo de la cadena» esta noticia no debería representar cambios a corto plazo, si no más bien tener la esperanza que ahora la organización de Internet estará en «manos de todos».

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Hace algunos meses el equipo de Webkit publicó su propuesta para crear degradados CSS; semanas atrás el equipo de Mozilla también publicó la suya (que será incluida en la siguente versión de firefox). Ambas propuestas son muy similares como veremos en los siguientes ejemplos.

Si queremos representar esta imagen como degradados usando CSS, con Webkit (528) la definición sería:

background: -webkit-gradient(linear, left top, left bottom, from(#00abeb), to(#fff), color-stop(0.5, #fff), color-stop(0.5, #66cc00));

Donde los parámetros corresponden a:

-webkit-gradient(tipo , punto inicio, punto final, color inicio, color final, color-stop(porcentaje, color), color-stop(porcentaje, color) ).

Con Firefox / Gecko (1.9.2) la definición solo varía al inicio, el resto de parámetros siguen en el mismo orden/significado:

background: -moz-linear-gradient(left top, left bottom, from(#00abeb), to(#fff), color-stop(0.5, #fff), color-stop(0.5, #66cc00));

Veamos un ejemplo más complicado, la imagen anterior se puede representar en Webkit de esta forma:

background: -webkit-gradient(radial, 45 45, 10, 52 50, 30, from(#A7D30C), to(rgba(1,159,98,0)), color-stop(90%, #019F62)),
-webkit-gradient(radial, 105 105, 20, 112 120, 50, from(#ff5f98), to(rgba(255,1,136,0)), color-stop(75%, #ff0188)),
-webkit-gradient(radial, 95 15, 15, 102 20, 40, from(#00c9ff), to(rgba(0,201,255,0)), color-stop(80%, #00b5e2)),
-webkit-gradient(radial, 0 150, 50, 0 140, 90, from(#f4f201), to(rgba(228, 199,0,0)), color-stop(80%, #e4c700));

background: -moz-radial-gradient(45px 45px, 10px, 52px 50px, 30px, from(#A7D30C), to(rgba(1,159,98,0)), color-stop(90%, #019F62)) no-repeat,
-moz-radial-gradient(105px 105px, 20px, 112px 120px, 50px, from(#ff5f98), to(rgba(255,1,136,0)), color-stop(75%, #ff0188)) no-repeat,
-moz-radial-gradient(95px 15px, 15px, 102px 20px, 40px, from(#00c9ff), to(rgba(0,201,255,0)), color-stop(80%, #00b5e2)) no-repeat,
-moz-radial-gradient(0 150px, 50px, 0px 140px, 90px, from(#f4f201), to(rgba(228, 199,0,0)), color-stop(80%, #e4c700)) no-repeat;

Pueden ver el código funcionando de estos ejemplos acá. A partir de estos podemos observar algunas diferencias:

• Para definir el tipo de degradado en Gecko se utiliza una propiedad diferente (-moz-linear-gradient) mientras que en Webkit se usa la misma propiedad (-webkit-gradient), pero se utiliza un parámetro adicional para indicar el tipo.
• En Webkit se especifican las posiciones y radios sin unidad de medida, pero se interpretan como si fueran píxeles. En el caso de Gecko se necesita indicar la unidad de medida. Ambos interpretan también medidas en porcentajes o palabras claves.
• En una misma definición de la propiedad background se pueden combinar tantos degradados como se necesite.
• En el caso de Gecko para los degradados radiales debemos especificar el parámetro no-repeat después de la definición de cada degradado, en el caso de webkit no hace falta hacerlo. Si en Gecko no está presente el parámetro no-repeat, entonces el degradado se repetirá en forma radial respecto al centro de este.

Diferencias respecto al usar imágenes

• Una de las primeras ventajas al definir degradados con CSS, es que eliminas las peticiones de las imágenes que hubiesen sido necesarias hacia el servidor web. Y de paso reduces el tiempo promedio para cargar del sitio
• Cambiar el CSS de un sitio es mucho más sencillo que modificar las imágenes necesarias para el diseño. Incluso puedes definir el CSS dinámicamente si fuera necesario, usando imágenes esto sería más complicado.
• Obviamente si lo incluyes en un sitio, muy poca gente será capaz de verlos. La versión actual de Firefox aún no los interpreta, tendrías que bajar la versión alpha para empezar a jugar con estos. En el caso de Webkit, las últimas versiones de Google Chrome y Safari ya interpretan los degradados CSS.
• Aún así del lado de los móviles (iPhone, Android, Pre, etc), las ultimas versiones de estos ya incluyen una versión de Webkit que los interpreta. Acá es donde yo les veo mayor opción a usarlos.

Un ejemplo más real

Imaginemos que tenemos un hipotético sencillo/ligero cliente para twitter que nos interesa que no desperdicie transferencia de datos en imágenes innecesarias (clave para usarlo sobre la red celular), pero a la vez queremos que no se vea tan feo como la interfaz móvil de twitter.

Nos interesa resaltar tweets de diferente color:

• Verde para los tweets propios
• Naranja para las respuestas/menciones
• Azul para los mensajes directos/privados
• Blanco para todo lo demás

Para ser compatibles con la mayor cantidad posible de navegadores, definiremos el color de fondo de cada tweet de esta forma:

#t li{
background:#FAFAFA;
background:-webkit-gradient(linear,left top,left bottom,from(#FAFAFA),to(#eaeaea));
background:-moz-linear-gradient(left top,left bottom,from(#FAFAFA),to(#eaeaea));
}

Primero usamos la definición más general, para que los navegadores que no interpretan los degradados CSS la usen, luego especificamos las definiciones para los navegadores que si los interpretan. Pueden ver el ejemplo de degradados CSS, si tienen la ultima versión de Google Chrome, Safari o la versión alpha de Firefox 3.6 deberían verlo así:

(clic en la imagen para ir al ejemplo)

Si este supuesto cliente lo usáramos en un iPhone, iPod Touch, Android, Palm Pre o cualquier otro que tenga un navegador con una versión reciente de Webkit, verían correctamente los degradados CSS. En la parte de Escritorio, la mayoría de gente aún usa Internet Explorer o Firefox, ninguno de estos interpreta los degradados CSS en sus versiones finales, no vale tanto la pena usarlos en algo general… por ahora.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Es acá donde encuentro muy útil Readabilty, un experimento de Arc90, un bookmarklet (sí, no necesitas instalar nada en el navegador) con el cual se eliminará el ruido de los sitios: barras laterales, encabezados, pies de página, comentarios, y sí, también elimina la publicidad, dejando únicamente el contenido.

Para usarlo sólo hay que eligir que configuración nos agrade (estilo de letra/colores, tamaño y ancho) agregar el bookmarklet a nuestro navegador. Luego al visitar una página que creamos valga le pena, se usa el bookmarklet para limpiar la vista. Por ejemplo, un típico artículo de Forbes.com, está tan cargado de ruido:

(clic para agrandar)

Después de usar Readability se nota tanto la diferencia:

(clic para agrandar)

Incluso en la pantalla de mi netbook o y no digamos en el iPhone se aprecia tener los contenidos así de cómodos/limpios. Aún cuando no funciona con todos los sitios y hay bastantes errores reportados, en la práctica funciona en los suficientes sitios como para volverse dependiente de este bookmarklet

¿Y mencioné que el código fuente de Readability está disponible bajo licencia Apache 2.0? Puedes descargar el código y ver como funciona, que por lo poco que revise si le dedicaron bastante tiempo.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Jeremy Orem de Mozilla comparte una solución alternativa con la cual no tengamos que instalar SQLite o siquiera cerrar Firefox. Todo es de ejecutar el siguiente comando desde la Consola de Errores (Menú Herramientas >> Consola de Errores):

Components.classes["@mozilla.org/browser/nav-history-service;1"].getService(Components.interfaces.nsPIPlacesDatabase).DBConnection.executeSimpleSQL("VACUUM");

Tan solo hay que copiar este comando y pegarlo en la ventana de la Consola de Errores y presionar el botón de Evaluar (no hay un aviso de cuando termina, pero se supone que Firefox quedará unos segundos colgado en lo que se ejecuta):

Esto solo afectará a places.sqlite, no al resto de bases de datos, pero de todos modos solo places.sqlite es la que se fragmenta más.

Si no quieren estar recordando este comando, pueden instalar la extensión (experimental) Vacuum Places Improved, que agregará un botón en la barra de estado después de X inicios, o procederá automáticamente a desfragmetar la base de datos después de otros tantos inicios de Firefox.

De parte de Mozilla aún siguen discutiendo sobre si deberían agregar esto a Firefox y cada cuanto tiempo ejecutarlo automáticamente.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

El equipo de Wordpress no se ha demorado y liberaron la versión 2.8.4 corriguiendo este problema que afecta al a rama 2.8.x, y posiblemente a las anteriores también.

El Ataque

Usualmente el proceso de reiniciar la contraseña requiere que se haga una confirmación al visitar una URL especial, que solo llegará a la cuenta de coreo del usuario en cuestión. Pero esta restricción se puede obviar al visitar una URL como:

http://misuperblog.com/wp-login.php?action=rp&key[]=

Lo que parece ser una petición inocente, tiene el detalle que la variable key está definida como un array (key[]=). El código de Wordpress válida que dicha variable no esté vacía:

if ( empty( $key ) )

Uno pensaría que esta comprobación debería ser suficiente, ¿no?

Aprendiendo un poco del ataque

Sabemos que la comprobación de Wordpress fallaba y según el parche oficial, decidieron agregar otra comprobación al if en cuestión:

if ( empty( $key ) || is_array( $key ) ) 

Entonces, ¿Cuál es el problema de usar solo empty( $key )? Resulta que en este caso $key no es un array vacío, sino que si contiene un elemento:

// si ejecutamos:
var_dump($_GET['key']);

// obtendríamos:
array (
  0 => '',
)

Lo cual viene a ser una particularidad inesperada de PHP, una que el equipo de Wordpress no tuvo en cuenta, y que a cualquiera de nosotros también podría pasar por la misma situación. Nos queda de lección que hay que limitar lo más posible el rango de valores posibles en las variables que estamos recibiendo del usuario, por ejemplo a mí se me ocurren estas otras dos opciones para limitar $key:

• Haciendo un CAST del valor:

$key = (string) $_GET['key'];
var_dump($key);

// Obtenemos:
'Array'

• Usando preg_match():

$r = preg_match('/[a-z0-9]*/i', $_GET['key'], $matches);

Al pasar un array en preg_match, obtenemos: Warning: preg_match() expects parameter 2 to be string, array given in blablabla.php on line XX. Pero de todos modos $r es false y $matches NULL

¿Alguna otra forma que se les ocurra a ustedes?

Moralejas: Actualicen Wordpress o apliquen el parche, y si son programadores revisen los valores que pueden tomar sus variables de decisión

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Nosotros usamos de base el plugin WPtouch, que es el que provee la versión para el iPhone, y sobre este hicimos que tuviera una plantilla «adicional». En la función detectAppleMobile del archivo wptouch.php:

• Hay un primer ciclo encargado de detectar los «agentes móviles» que deseamos usen la versión para el iPhone.
• Si no es uno de estos hay un segundo ciclo que intentará ver si es otro agente al cual hay que mostrar la versión más sencilla para móviles, como Opera Mini, IE Mobile y otros navegadores raros menos populares
• Si ninguno de los ciclo encontró un «agente móvil», entonces se asume que es un cliente de escritorio al que hay que mostrar la plantilla «normal» del sitio, la plantilla que ustedes ya conocen desde el rediseño del sitio

En código, dicha función quedará así:

function detectAppleMobile($query = '') {
	$container = $_SERVER['HTTP_USER_AGENT'];
	$useragents = array("iphone", "ipod", "aspen", "dream", 'android');
		$this->applemobile = false;
	foreach ($useragents as $useragent) {
			if (eregi($useragent, $container)) {
				$this->applemobile = true;
				$this->is_iphone = true;
		}
	}

	// if not iphone
	if ( !$this->applemobile ) {

	$browserAgents = "Elaine/3.0, Palm, EudoraWeb, Blazer, AvantGo, Windows CE, Cellphone, Small, MMEF20, Danger, hiptop, Proxinet, ProxiNet, Newt, PalmOS, NetFront, SHARP-TQ-GX10, SonyEricsson, SymbianOS, UP.Browser, UP.Link, TS21i-10, MOT-V, portalmmm, DoCoMo, Opera Mini, Palm, Handspring, Nokia, Kyocera, Samsung, Motorola, Mot, Smartphone, Blackberry, WAP, SonyEricsson, PlayStation Portable, LG, MMP,OPWV, Symbian, EPOC";
	$browserAgents = explode(',',$browserAgents);
	if(!empty($browserAgents)){
		foreach ($browserAgents as $key => $value){
			$browserAgents[$key] = trim($value);
		}
	}

	foreach ( $browserAgents as $userAgent ) {
		if(eregi($userAgent,$container)){
			$this->applemobile = true;
			$this->is_iphone = false;
			//return;
		}
	}

	} //if ( !$this->applemobile )
	$this->bnc_filter_iphone();
}

Una vez ejecutado esto, ya solo tenemos que ver el valor de $this->applemobile para saber si es un «agente móvil» y $this->is_iphone para saber si le vamos a mostrar la versión para el iphone o no.

Luego de esto, tomamos nuestra plantilla basada sobre MobilePress y la llevamos hacia el directorio de plantillas del WPtouch (si el plugin ya tiene esto): /wp-content/plugins/wptouch/themes/. Hecho esto ya solo tenemos que especificarle a Wordpress el directorio de la plantilla que deseamos usar:

function get_stylesheet($stylesheet) {
	if ($this->applemobile && $this->desired_view == 'mobile') {
		if ( $this->is_iphone )
			return 'default'; // './wptouch/themes/default'
		else
			return 'pda'; // './wptouch/themes/pda'
	} else {
		return $stylesheet;
	}
}

function get_template($template) {
	$this->bnc_filter_iphone();
	if ($this->applemobile && $this->desired_view === 'mobile') {
		if ( $this->is_iphone )
			return 'default'; // './wptouch/themes/default'
		else
			return 'pda'; // './wptouch/themes/pda'
	} else {
		return $template;
	}
}

El cambio de plantilla solo se hace si $this->applemobile tiene el valor true, de lo contrario se usará la que esté configurada desde Wordpress.

Con estas modificaciones a estas 3 funciones en wptouch.php ya deberíamos tener funcionando las diferentes plantillas según el agente desde el cual nos visitan.

Compatibilidad con WP-Cache

Para los que usamos WP-Cache nos encontramos con el problema de que usar diferentes plantillas dinámicamente no funciona correctamente con el caché activo, hará que la página se guarde de acuerdo al visitante con el cual se generado; los siguientes visitantes verán la misma versión que el primero.

A pesar de que el autor de WPtouch ofrece una versión modificada de WP-Cache que debería corregir esto, no funciona. Si una página ya está guardada en caché con la versión «normal», todos verán esta versión sin importar que agente usen.

Nosotros decidimos modificar WP-Cache para que detecte que agente se está usando y decida se mostrará o no la página en cache, una modificación a wp-cache-phase1.php resuelve esto:

global $cache_rejected_user_agent;
if ( function_exists('apache_request_headers') ) {
	$headers = apache_request_headers();
	if ( isset($headers["User-Agent"]) ) {
		foreach ($cache_rejected_user_agent as $expr) {
			if ( strlen($expr) > 0 && stristr($headers["User-Agent"], $expr))
				return; // sale por completo de wp-cache
		}
	}
}

$cache_rejected_user_agent (definido en wp-cache-config.php) es un array con los nombres de los agentes móviles que deseamos no vean ninguna página en caché, y pase el control hacia Wordpress. Como nuestro tráfico desde estos agentes es muy poco, no representa mayor esfuerzo para el servidor. El día que dicho trafico nos genere problemas, la mejor opción será especificar un directorio diferente para cada plantilla que usemos (controlado por $cache_path).

Bonus: Usar un dominio diferente al principal

Si han entrado a maestrosdelweb.com desde un móvil, verán que son redirigidos hacia maestrosdelweb.mobi, lo hicimos para darle algo de movimiento a dicho dominio y cumplir el propósito del TLD.

El primer paso es indicarle a Wordpress (en el wp-config.php) que use un dominio diferente al configurado en la base de datos, según la petición:

if ( $_SERVER['HTTP_HOST'] == 'maestrosdelweb.mobi' || $_SERVER['HTTP_HOST'] == 'www.maestrosdelweb.mobi' ) {
	define('WP_HOME', 'http://maestrosdelweb.mobi');
	define('WP_SITEURL', 'http://maestrosdelweb.mobi');
}

(más detalles sobre estas variables en el Codex de Wordpress)

Hecho eso, agregamos a la función detectAppleMobile() de wptouch.php otra condición para redirigir los móviles hacia el dominio .mobi:

if ( ($_SERVER['HTTP_HOST'] == 'maestrosdelweb.com' || $_SERVER['HTTP_HOST'] == 'www.maestrosdelweb.com') && $this->applemobile) {
		header('Location: http://maestrosdelweb.mobi'.$_SERVER['REQUEST_URI'] );
		die;
	}

Obviamente ya debimos haber detectado si es un agente móvil o no, con los ciclos mencionados al inicio de este post. Por último necesitamos redirigir cualquiera que esté entrando al dominio .mobi y que no sea desde uno de los agentes móviles. Esto lo hacemos en wp-cache-phase1.php justo después del ciclo mencionando anteriormente para wp-cache:

if ( ($_SERVER['HTTP_HOST'] == 'maestrosdelweb.mobi' || $_SERVER['HTTP_HOST'] == 'www.maestrosdelweb.mobi') ) {
		header('Location: http://www.maestrosdelweb.com'.$_SERVER['REQUEST_URI'],true,301);
		die;
}

Y con esto nuestro hack para el cambio de dominio estará listo.

Nos gustaría compartirles la versión final del plugin, ya combinada con MobilePress, pero dado que hicimos algunas personalizaciones a medida y es complicado mantener actualizaciones dependiendo de un tercero; preferimos contarles la historia completa de como reproducir ese cambio. A lo mejor alguien se anima a mantener dicha mezcla de plugins

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Me recuerda que ni hay proveedor infalible, y eventualmente todos tendrán que fallar, según la Ley de Murphy, así es como funcionan las maquinas, no son perfectas. Por experiencia propia con los proveedores de hosting, se que los dominios pueden dejar de resolver correctamente

Algunas personas por razones de marca (branding) usan su nombre de dominio para sus direcciones de correo electrónico; ya sea que usen el servidor de correo incluido en el servicio, o uno externo como el de Google Apps. Dependiendo del negocio entorno al nombre dominio, tal vez no sea tan critico que el sitio web esté fuera por algunas horas, en comparación a perder la comunicación con el correo.

Si estas usando tu nombre de dominio para tus direcciones de correo, entonces deberías estar usando un servidor de DNS’s externo, o al menos contar con algún tipo de redundancia:

• Espera tener algún tipo de problema al usar los servidores DNS de tu hosting compartido (principalmente si es un proveedor no tan grande).
• No dependas de un solo nameserver en tu VPS o servidor dedicado (ya cometimos ese error), si tienes varios servidores agrega el mismo dominio a diferentes zonas de autoridad (aún cuando el sitio este hospedado solo en uno)
• Si no tienes varios servidores, entonces mejor considera contratar un servicio de DNS’s

He visto varios servicios de DNS como Zone Edit, DnsMadeEasy o EasyDNS, pero tan solo ver sus sitios no me dieron mucha confianza (lucen tan desactualizados). Yo llevo algunos meses usando DynDNS y su servicio de Custom DNS, no he tenido ningún problema con ellos y se nota que se esmeran en estar al día.

Otra opción puede ser utilizar los servidores DNS del registrador de dominio donde tengamos el dominio, puede que sea gratuito o no, pero al menos será mejor que el de un shared hosting.

La ventaja de tener los DNS’s en un proveedor de hosting, es que puedes cambiar el sitio de proveedor más rápido, sin tener que esperar varios días a que la nueva «zona de autoridad» se propague; solo estarías modificando los registros A que por experiencia propia se reflejan más rápido que los cambios de zona.

Uno pensaría que se está agregando otra “capa” al sistema que podría fallar, pero justamente por eso se debe buscar un proveedor confiable (en mi caso DynDNS) que ofrezca una mejor redundancia que un proveedor de hosting. Una desventaja de usar un servidor DNS externo, es que si usas un hosting compartido, tienes que estar pendiente de los cambios de la IP del sitio, ya que no te ofrecen una ip estática para ti solo.

Obviamente no todos los dominios que mantengamos valen la pena pagar y tomarse la molestia de contratar/mantener un servidor DNS adicional, y ese es el punto: si un dominio nos genera ingresos, o el solo hecho de que esté fuera de linea nos causa perdidas, justifica el que invirtamos un poco más de dinero para prever/minimizar problemas que puedan surgir con este; esto es algo que seguro a muchos nos ha pasado.

Imagen: Tango Desktop Project.

Otros recursos que pueden ser útiles

• Haz que tu servidor se defienda por si mismo contra ataques (D)DoS
• Guía para trasladar tu sitio de hosting sin dejarlo abajo ni un minuto
• ¿Problemas con los DNS’s de tu ISP? Usa OpenDNS
• Herramientas para revisar la configuración de nuestros servidores DNS

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

En un mundo perfecto eso no sería nada de que preocuparse; pero en el mundo real la gente con grandes cantidades de archivos temporales, antivirus instalados y discos con límites en la velocidad lectura, está viendo como Firefox 3.5 tarda hasta varios minutos en cargar, calificando esto como un fiasco para Mozilla.

Ya se ha identificado el bug y se espera que en la versión 3.5.1 se resuelva esto, mientras tanto la solución es eliminar todos esos archivos temporales con tal de mejorar el inicio de firefox. Específicamente, 3.5 leerá estos directorios:

C:\Documents and Settings\*usuario*\Local Settings\History
C:\Documents and Settings\*usuario*\Local Settings\Temporary Internet Files
C:\Documents and Settings\*usuario*\My Recent Documents
C:\Documents and Settings\*usuario*\Temp\

(Usuarios de windows 7 o vista, ya saben que es C:\Users en lugar de C:\Documents and Settings)

Ya sea que eliminen estos archivos a mano o desde las opciones de Internet Explorer, definitivamente mejora el inicio. En mi uso diario como casi siempre dejo la PC en hibernación, el proceso de Firefox pasa días corriendo, pero si hay una mejora notable del antes y después de eliminar esos archivos.

Ahora, Firefox no solo va a necesitar que defragmenten sus bases de datos sqlite, sino que ahora debes borrar los archivos temporales de tu sistema y de Internet Explorer… genios!

PD: Espero que en los comentarios no me digan que no es un problema de Firefox, sino de Windows en sí…. o que debería usar un navegador de esos que salen de premio en las cajas de cereal :rolleyes:

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Desde el día jueves por la noche he tenido problemas para acceder (con Turbonett) a cualquier blog hospedado en los servidores de Wordpress.com (incluido el mío), la única forma por la cual se puede lograr acceder a estos es usando una ruta alterna por medio de algún tunel o proxy, con lo que pude confirmar que era un problema con la ruta por la cual pasa mi enlace.

No es un problema en los DNS, ya que usando OpenDNS puedo resolver correctamente la IP de todos los sitios en Wordpress.com:

C:\>nslookup wordpress.com
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    wordpress.com
Addresses:  72.233.2.57
          74.200.243.254
          76.74.254.126

Pero luego aún con un simple ping no hay respuesta:

C:\>ping wordpress.com

Pinging wordpress.com [74.200.243.254] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 74.200.243.254:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

¿Por qué no habría acceso a Wordpress.com desde Guatemala?

Sabemos que no es un problema de todos los proveedores locales, sino solo algunos de estos, y el soporte técnico de estos solo dice que está investigando el problema. Podría existir la mala fortuna que estos proveedores compartan la misma salida de Internet y el problema esté en esta. Además sabiendo que el problema inició cerca del fin de semana podría pensarse que estaban haciendo algunos cambios en sus infraestructuras.

Que quede claro: Aún no hay ninguna confirmación “oficial” sobre si en verdad existe un bloqueo intencional, o solo un error en el ruteo de la salida de Internet en Guatemala; Esperamos que solo sea un misterioso problema técnico.

Hasta ahora he podido confirmar (con turbonett) que todos los blogs y dominios en los DNS’s de Wordpress.com, Automattic.com, Buddypress.org, bbpress.org y Wordpress.org no hay acceso hacia estos. Otros proyectos de Automattic, como Akismet, Gravatar o IntenseDebate aún se pueden acceder sin problemas.

Para los usuarios en Guatemala, pueden confirmar si tienen o no acceso hacia Wordpress.com y sitios relacionados en HerdictWeb.

Alternativas para acceder a Wordpress.com

En lo que se aclara este asunto, a los usuarios en Guatemala que necesitemos acceder a Wordpress.com, nos tocará:

• Usar Proxys internacionales
• Instalar TOR
• O usar una VPN, que es la solución más “Pro”

Y claro, tal como recomienda @romerogt, los usuarios de estos provedores deberían reportar el problema para que sea resuelto lo antes posible. En twitter estaremos siguiendo el tema usando el hashtag #wordpressgt

Otros usuarios que han compartido sus opiniones al respecto

• El Profe:Wordpress bloqueado en Guatemala
• El Blog del Baterista: Acceso desde ISP de Telgua a wordpress.com restringido
• Micha Micha: Bloquedo de Wordpress en Guatemala
• Bitacora de RomeroGT: Turbonett y Tigo no dejan llegar a Wordpress en Guate
• El abismo de Tux: ¿Como me respondieron en tigo acerca del bloqueo de wordpress.com?

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

¿A qué viene todo esto? Resulta que hace unas pocas horas el identificador de cada estado en Twitter, pasó el límite de los enteros de 32bis (con signo) o sea, 2,147,483,647; a lo que le han denominado el Twitpocalypse, el problema no es con Twitter, sino con las aplicaciones que no están preparadas para enteros más grandes que dicho límite.

Las «víctimas» más notables del Twitpocalypse, han sido Twitterrific para el iPhone, TwitterDeck y Destroy Twitter, estos dos últimos ya liberaron nuevas versiones corrigiendo el error y Twitterrific debe esperar el lento/ineficiente proceso de la App Store para que vemos una nueva versión.

Pero esto no se limita solo a clientes de escritorio, seguro también afectará a servicios en linea que dependan de Twitter en alguna forma. Por ejemplo en un script PHP en el que estoy trabajando, por limitar el tipo de datos que inserto a la base de datos estoy haciendo una conversión lo que obtengo de la API de Twitter:

$updateid = (int) $status->id;

El detalle está en que si PHP corre sobre una plataforma de 32bits, el máximo entero es:

$ php -r 'echo PHP_INT_MAX;'
2147483647

Mientras que en una plataforma de 64bits, será:

$ php -r 'echo PHP_INT_MAX;'
9223372036854775807

Al no a ver tenido en cuenta esta sutil diferencia, mi script se ha perdido de algunos tweets en lo que me percaté del problema, en fin gajes del oficio. Al final, lo solucioné de esta forma:

$updateid = (float)$status->id;

// o incluso podría ser:
$updateid = abs( (float)$status->id ); // solo por limitarlo más   

Y claro si están guardando los tweets en alguna base de datos, hay que revisar el tipo de datos para el identificador… de preferencia que sea BIGINT si usan MySQL.

Si notan que alguna aplicación o servicio ha dejado de funcionar recientemente y sin razón alguna… ya saben que es lo que pudo haber pasado. Seguro que dentro de las próximas horas saldrán nuevas versiones… y sino, será mejor buscar alguna alternativa a la cual si le presten más atención.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Uno de los últimos problemas que estuve sufriendo fue el increíble tiempo para que Firefox 3.5b4 iniciara, tomando más de un minuto y muchísimos accesos al disco duro; cosa que no pasaba con mi Firefox 3.0.10.

El problema viene que Firefox usa bases de datos en SQLite (desde 3.0) para guardar el historial, marcadores, cookies, datos en formularios, etc; y luego de muchos meses de uso bases de datos se fragmentan lo cual afecta el rendimiento al inicio de Firefox (en mi caso tengo 28MB en archivos *.sqlite) y este nunca compacta dichas bases de datos.

Para solucionar le problema hay que correr el comando VACUUM de SQLite, que sería un equivalente del OPTIMIZE TABLE en MySQL, esto eliminará todos los espacios del archivo de la base de datos eliminando los fragmentos en este.

Para hacerlo necesitas SQLite, tendrás que descargarlo o instalarlo con algún administrador de paquetes como el de Debian/Ubuntu:

sudo apt-get install sqlite3

Una vez instalado SQLite y accesible desde el PATH, cierren Firefox para que las bases de datos no estén bloqueadas, busquen en que directorio está su perfil de Firefox:

En Debian/Ubuntu sería en:

/home/[username]/.mozilla/firefox/[profile-id]

Para Windows:

C:\Documents and Settings\[username]\Application Data\Mozilla\Firefox\Profiles\[profile-id]

En dichas carpetas deberían estar varios archivos *.sqllite. Una vez sepan la ruta, hay que correr el comando:

sqlite3 places.sqlite "VACUUM"

places.sqlite es el archivo más grande en mi caso, donde firefox guarda el historial de navegación, pero también pueden correrlo sobre el resto de archivos *.sqlite

Completados estos pasos, al iniciar nuevamente Firefox, deberían notar que se tarda menos tiempo en iniciar, dependerá de cada instalación en cuanto tiempo y espacio puedan ganar.

Actualización: Marcelo ha creado un archivo .bat y un .zip que incluye lo necesario para hacer esta optimización a firefox mucho más sencilla a los usuarios de Windows.

Imagen: intothefuzz.com.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page

Pero hay que aceptar que a pesar de todo, OpenDNS tiene dos inconvenientes que hay que resaltar:

Privacidad

Creo que este es el punto que más les ha preocupado a muchos: por defecto OpenDNS utiliza un Proxy para que algunas características del servicio funcionen pero lo curioso es que hacen que todas las peticiones a Google pasen por su proxy:

C:\>nslookup www.google.com
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    google.navigation.opendns.com
Addresses:  208.69.32.231, 208.69.32.230
Aliases:  www.google.com

OpenDNS aclara al respecto de porque esto es así:

When enabled, we route certain requests to a simple proxy which checks for the origin of the request. Shortcut-related traffic gets handled (and redirected) while all other traffic goes to the intended destination untouched. We are not storing or mining any of the data that passes through the proxy. The proxy does nothing malicious – it’s designed to make your shortcuts work seamlessly with the Google Toolbar and similar services, giving you the best of both worlds.

También declaran que se usaran los datos solamente para motivos operacionales y prometen cumplir con su política de privacidad. De todas formas esta característica se puede desactivar (a costa de que dejen de funcionar los “network shorcuts”), todo lo que necesitas es:

• Crear una cuenta de usuario en OpenDNS
• Garantizar que tu cuenta esté ligada a tu última dirección IP “pública”. Si tienes una IP estática, basta con registrar tu red una vez en OpenDNS; si se te asigna una IP dinámica, podrías usar uno de estos programas para mantener actualizada tu IP con tu cuenta (Windows y Mac OSX).

Una vez resuelto esto, solo tienes cambiar la configuración de tu red en OpenDNS (Advanced Settings) para que no esté activo su proxy:

Minutos después, ya deberías conectarte directamente a los servidores de Google, como si no existiera el proxy de OpenDNS:

C:\>nslookup www.google.com
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    www.l.google.com
Addresses:  64.233.161.147, 64.233.161.104, 64.233.161.99
Aliases:  www.google.com

OpenDNS Guide

Cuando uno escribe mal un nombre de dominio, espera recibir un aviso de que no es posible conectarse al dominio, o simplemente no funciona en ese instante; pero cuando uno está detrás de los servidores de OpenDNS, uno termina siendo redirigido hacia el OpenDNS Guide:

(clic para visitar)

Incluso si uno hace una consulta a los DNS’s por un dominio inexistente, recibirás una respuesta de como que si existiera y resolviera hacia una IP (de OpenDNS obviamente):

C:\>nslookup sdfsdfsdfsdfsd.com
Server: resolver2.opendns.com
Address: 208.67.220.220

Non-authoritative answer:
Name: sdfsdfsdfsdfsd.com
Address: 208.69.34.132

Esa es una de las características que más detesto de OpenDNS, lo bueno es que de todos modos también se puede desactivar: de nuevo se necesita una cuenta, y mantener la IP “pública” ligada a esta. Solo tenemos que desactivar las correcciones de nombres de dominios (domain typos) en la configuración de nuestra red:

Minutos después de guardar esto, ya no tendrías que seguir viendo el OpenDNS Guide en cada error o búsqueda que hagas desde la barra de direcciones del navegador.

La parte más complicada de esto es estar actualizando la IP desde la que OpenDNS te reconoce, sobre la privacidad honestamente me preocupa mucho más lo que hacen los Gobiernos y Proveedores locales que lo que haría OpenDNS.

Javier Aroche para Maestros del Web.
Agrega tu comentario | Enlace permanente al artículo

Síguenos en: @maestros | Fan page