unreal4u's Personal Network » Mundo Web

Algunas notas sobre el prefetching

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

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

¿Qué es el prefetching?

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

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

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

Preparación

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



	Testing prefetch with HTML5
	
	
	

Please click here to display the (prefetched) page

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

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

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

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

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

Empiezan las sorpresas

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

Primero dos links que me fueron de mucha ayuda:

http://browserspy.dk/prefetch.php

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

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

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

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

¿Qué pasa con Firefox?

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

Conclusiones

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

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

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

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

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

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

Firefox5 + IE9 y su nueva forma de redireccionar

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

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

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

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

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

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

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

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

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

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

Regiones, provincias y comunas de Chile en SQL

unreal4u — Mon, 14 Mar 2011 04:16:45 +0000

Hacía ya algún tiempo atrás, necesitaba un listado (actualizado) de las regiones y ciudades (o mejor dicho comunas, ya que no existen ciudades en Chile) en SQL y a pesar de que podría ser bastante común, me costó encontrar alguna. Así que les presento una página que de casualidad corresponde a un amigo mío que se dio el trabajo de agregar y corregir el SQL para distintos motores y en distintos formatos de acuerdo al decreto 817 del 20 de mayo del 2010.

Revisen el siguiente post: Lacosox
Y por supuesto, también queda una copia local aquí por si se cae el primer sitio: Archivo .zip

¿Es tan difícil rankear mejor en Google?

unreal4u — Wed, 03 Nov 2010 02:32:57 +0000

A través de los años, he visto miles de propagandas mágicas de algunos SEO que prometen elevar un sitio X hasta los primeros lugares en Google (por lo general no toman en cuenta otros buscadores).
Este hecho en sí no deja de sorprenderme mucho, ya que algo sé del asunto y diría que en un mes es bastante difícil lograr ese objetivo. Verán, los principales atractivos para Google son primero el tener la antigüedad; segundo; la calidad del contenido, y tercero: velocidad de actualización.
Lo siguiente es una opinión personal sobre cuáles son los puntos que considero más importantes para ascender rápidamente en un océano de información.

Parece sorprendente que una compañía como Google tome tan en cuenta la antigüedad de un sitio, pero es así: mientras más antiguo un sitio, mayores son las probabilidades de aparecer rankeado dentro de los primeros lugares de una búsqueda; básicamente porque si la página tiene sus años online, significa que los dueños de la misma son personas constantes.

Sin embargo, el hecho de que la página esté siempre arriba no significa necesariamente que su contenido esté siempre actualizado: perfectamente puedo tener alojada en página en algún servidor como geocities y nunca actualizarla. En este caso, por muy antigua que sea mi página, no va a tener mayor relevancia ya que tiene poca actividad y una de las cosas que más penan en Internet es que es un medio de rápido consumo: actualiza o muérete.

La calidad del contenido es obviamente importante también. No es lo mismo un artículo de 3 palabras a un artículo que tenga una introducción, historia, antecedentes, desarrollo y finalmente conclusiones acerca del tema. El segundo obviamente en cuanto a calidad es mucho mejor; y Google; habiendo nacido como un indexador de una biblioteca, sabe cuándo un tema está bien explicado y cuándo no.

Ahora bien, eso no quiere decir que absolutamente todo se trate de antigüedad o calidad: también influye muchísimo la limpieza del código (combinado con un buen markup se hacen maravillas), las niceurl y por supuesto: los backlinks.
Lo primero es importante ya que un código limpio significa que lo más probable es que el sitio está preparado para ser visualizado en un montón de dispositivos distintos (por una razón muy simple: si te preocupaste de tener un código limpio, lo más probable es que también te hayas preocupado de probarlo en distintos dispositivos): desde navegadores en distintas plataformas hasta dispositivos móviles con todo tipo de pantallas y resoluciones: mézclalo con buenos contenidos actualizados constantemente y obtendrás un boost inmediato donde nuestro querido tío Google. Mejor aún si tienes un buen markup: diferenciando claramente entre un elemento y (uno es semántico mientras que el otro denota importancia) y estructurando el documento de tal forma que primero venga un

y finalize en párrafos y demases elementos.

Las niceurl no son nada más que url's feas re-escritas de manera bonita. De esta forma, ejemplo.com/index.php?s=344&asdf=qwerty se puede convertir en algo como ejemplo.com/344/qwerty/ lo cual es mucho más fácil de memorizar y por supuesto, de escribir. Aunque no lo crean, esto sí tiene una importancia, aunque no tan notoria como las demás.

Los backlinks no son otra cosa que los links que apuntan a nuestra página. ¿Alguna vez han querido encontrar algo bastante específico y se dan cuenta que ese único documento se repite una y otra vez? Alguien tuvo que haberlo escrito alguna vez y la razón del por qué se cita tanto ese documento con origen tan común es debido a que debe estar bastante bueno. Mientras más backlinks, mejor contenido tendrá por lo que será más relevante en los términos de búsqueda.

Recapitulando y ordenando (AKA conclusión)

Hasta el momento he divagado acerca de varias técnicas que permiten ascender el número de visitas de una forma rápida y fácil. Sin embargo, no las he ordenado. A continuación, voy a enumerar lo expuesto en este post de la más a la menos importante:

Calidad de la Información

Backlinks

Velocidad de Actualización

Antigüedad

Limpieza de Código

Niceurl

Cabe destacar que sólo analicé 6 puntos... de un listado general de más de 50 variables. Sin embargo, creo que éstos son según mi punto de vista los más importantes.

¿Qué les ha parecido esta lista? ¿Agregarían o modificarían el orden de la misma? ¿Faltó alguna variable que consideran importante? Espero sus comentarios

Habilitar salida de errores en Magento

unreal4u — Mon, 18 Oct 2010 03:51:19 +0000

Si alguna vez les ha salido el mensaje "Exception printing is disabled by default for security reasons" entonces sabrán que algo se hizo mal. Sin embargo, tampoco podremos saber qué salió mal, algo relativamente importante en el caso de que estemos desarrollando algún plugin o modificando algunos comportamientos del mismo Magento.

Para activar la salida de errores, basta modificar un archivo:

cd /magento/ cp errors/local.xml.sample errors/local.xml

Y listo! Con este tip ya pueden revisar el trace que genera Magento y poder solucionar sus errores rápidamente.

PHP, SimpleXML y el famoso CDATA

unreal4u — Thu, 14 Oct 2010 14:02:52 +0000

PHP tiene -a mi gusto- una de las mejores librerías para trabajar con XML: SimpleXML. Crear un documento XML con SimpleXML es realmente simple, ya que basta agregar nodos hijos con sus respectivos atributos y estaría listo el documento. Sin embargo, SimpleXML sólo tiene una caída bien fea: el no saber tratar documentos que contengan CDATA.

El CDATA dentro de los documentos XML sirve para expresar contenido en HTML y le indica al navegador (también a Adobe Flash) que no debe parsear su contenido, esto quiere decir que debe interpretar la cadena "Hola mundo" dentro de un párrafo así:

<[CDATA[
Hola mundo
]]> // y no así: >p<Hola mundo>/p<

Estuve buscando bastante por todos lados para encontrar alguna forma de poder incorporar este tipo de dato en un documento XML, y para mi mala suerte, lo único que encontré fue cómo leerlo, pero no la escritura.
Eso hasta que me encontré con un post bastante corto pero conciso que hablaba sobre el tema y que para mejor suerte mía, tenía un pedazo de código que me pareció obvio... una vez que lo vi:

class SimpleXMLExtended extends SimpleXMLElement { public function addCDATA($cData) { $node = dom_import_simplexml($this); $no = $node->ownerDocument; $node->appendChild($no->createCDATASection($cData)); } }

Esa class, que extiende las funcionalidades de la implementación predeterminada de SimpleXML en PHP, nos permite agregar una función que nos permite combinar SimpleXML con DOM (que sí tiene soporte para CDATA) y devuelve un objeto SimpleXML.

De esta forma, lo único "distinto" es que en vez de ocupar:

$xml_raiz = simplexml_load_string(''); // Ahora será: $xml_raiz = new SimpleXMLExtended(''); // Agregando CDATA: $texto = $xml_raiz->addChild('el_html'); $texto->addCDATA(htmlentities('
El contenido en HTML
'));

Lo de arriba devolvería algo muy parecido a:

<[CDATA[
El contenido en HTML
]]>

Para finalizar, un pequeño tip para poder habilitar la lectura de CDATA en SimpleXML: basta abrir el XML con una directiva especial, LIBXML_NOCDATA:

$lol = simplexml_load_file('el_archivo.xml', NULL, LIBXML_NOCDATA);

Fuente: coffeering's posterous

Magento: sus índices y modificación de stock y precios

unreal4u — Tue, 05 Oct 2010 22:31:14 +0000

Tuve la suerte de conocer este año Magento: una plataforma de e-commerce, muy completa y que apenas lleva un año rondando en la Web. Sin embargo, ha sido por un lado una fortuna y por otro, una des-fortuna conocer este CMS.
Fortuna debido a que está muy bien hecho, 100% orientado a objetos y realizado con el framework de Zend. Tiene algunas opciones muy avanzadas y en general el planteamiento mismo de la base está muy bien hecho. Así por ejemplo, la base de datos implementa un esquema tipo EAV el cual, en un principio, puede parecer complicada. Sin embargo, con el tiempo uno va viendo que es mejor así. Lo otro que también está muy bien hecho, es su sistema de templates.

Sin embargo, también ha sido una des-fortuna debido a su complejidad inicial y su pobre documentación. No existe un lugar centralizado que sea bueno donde hayan tips, consejos, descripción de métodos y otros y mucha información uno la puede ir sacando a través de los distintos blogs que existen.

Por lo mismo, en esta entrada compartiré con ustedes cómo hacer una modificación externa de los precios y stock (en la empresa donde trabajo hay un ERP con el que se trabaja y es, en estricto rigor, el que manda), para que de esta forma, Magento pueda estar al tanto de todas las modificaciones de precios y por supuesto, de stock.

Rápido barniz

Para actualizar el stock y el precio de forma externa, primero debemos actualizar la base de datos. Esto se hace con las siguientes consultas:

-- Precio: UPDATE catalog_product_entity_decimal SET value = '43000.00' WHERE attribute_id = 64 AND entity_id = $a['entity_id'] -- Stock: UPDATE cataloginventory_stock_item SET qty = '23',is_in_stock = '.$is_in_stock.' WHERE product_id = $a['entity_id']

Dos notas:
1.- $a['entity_id'] se refiere a la id interna que Magento le asigna al producto en sí. No es difícil de sacar, involucra estas tablas:
catalog_product_entity catalog_product_entity_decimal cataloginventory_stock_item
2.- $is_in_stock puede tener dos valores: 0 si el stock es igual o menor a 0, ó 1 si es mayor que este valor. En breve:

if ($b['qty'] > 0) $is_in_stock = 1; else $is_in_stock = 0;

Hasta ahí todo bien: en el administrador podemos darnos cuenta de que los productos con stock tienen ingresado el nuevo stock y que también tienen sus precios al día. Sin embargo, aquí empieza lo bueno: ¡en el frontend no hay ningún cambio!
Afortunadamente, leí en un blog que se puede reconstruir el índice de forma automática y que (mejor aún) existe un programa para hacer esto: shell/indexer.php.

En breve:

crontab -e # una vez dentro */30 * * * * /usr/bin/php /home/[usuario]/erp/actualiza.php && /usr/bin/php /home/[usuario]/public_html/shell/indexer.php reindexall >/dev/null 2>&1

La última parte (>/dev/null 2>&1) es para que no se mande un mail al usuario cada vez que se ejecute un cron. En este mail irá toda la salida que se produzca así que puede ser bueno eliminar ese código por motivos de depuración.

Y aquí es donde entra la curiosidad: indexer.php, al pasarle el parámetro reindexall reindexa absolutamente todos los índices... no sería mejor reconstruir sólo el del stock? Me puse a investigar y me encontré con el comando indexer.php --info, que retorna la siguiente salida:

catalog_product_attribute Product Attributes catalog_product_price Product Prices catalog_url Catalog URL Rewrites catalog_product_flat Product Flat Data catalog_category_flat Category Flat Data catalog_category_product Category Products catalogsearch_fulltext Catalog Search Index tag_summary Tag Aggregation Data cataloginventory_stock Stock Status

Todos esos atributos podemos pasarle al script para que reindexe sólo uno de los índices y alivianar la pega del servidor.

Y eso sería todo por hoy, espero que les haya servido Quizás, pero muy quizás en una próxima entrega, explicaré un poco el asunto de los templates en Magento.

Solución a problemas comunes en tchile

unreal4u — Fri, 24 Sep 2010 17:59:22 +0000

Muchas veces, cuando algún cliente me contacta, ya se ha comprado el dominio y el hosting (Lo cual es una excusa más para no seguir perdiendo plata y que esté la página arriba rápido). Y dentro del universo de hostings, tchile es tal vez el hosting más popular en Chile, casi todos mis clientes tienen su página hosteada ahí.
Sin embargo, no todo es color de rosas. He tenido bastantes problemas en el pasado por páginas subidas ahí y también -como no- hasta WordPress con el theme predeterminado simplemente me mostraba una página en blanco cuando intentaba editar o crear un nuevo post.

Por lo tanto, opté por lo sano y me puse a investigar todas aquellas cosas que es bueno desactivar cuando tenemos que montar alguna página en este hosting.

Primero debo partir subrayando el hecho de que tchile no es un hosting malo, por el precio es bastante bueno y el soporte responde, aunque se demora su buen resto. En general tienen buen uptime y en el transcurso de los últimos 6 meses he podido contabilizar unas 3 caídas graves. Algo rescatable es que, si bien es cierto el servicio estuvo caído mayormente el 19 de febrero, el 27 de febrero (y posterior) estuvo siempre arriba.
Sin embargo, tchile -como cualquier otro hosting en Chile- comparte una misma regla: atrévanse a crecer mucho en visitas y cualquier hosting chileno dará jugo. (Donde muchas visitas está determinado por 25.000+ visitas únicas diarias). Ante esa eventualidad, es mil veces mejor hostearse en Estados Unidos, donde los precios, atención y uptime son muy superiores a lo que les puede ofrecer cualquier hosting en Chile.

Primer gran obstáculo: caché

Me ocurrió una vez que quise instalar osCommerce que subía el index... lo visitaba una vez, actualizaba y veía el index de hace 1 mes, lo mismo con las demás páginas estáticas. Bueno, básicamente lo que pasaba era que Apache al ver que el documento no se había modificado de la última vez que se visitaba la página, resolvía entregar la que tenía en caché... el único problema es que no había actualizado la caché con lo cual entregaba la antigua. Grave problema.

Para resolver esto, apliqué un pequeño y sucio hack, que es mandar la cabecera con modificación en el pasado. De esta forma, le estoy diciendo a Apache que cualquier request me la tiene que procesar y no devolver desde la caché. Cómo se hace esto? De la siguiente forma:

header('Expires: Tue, 03 Jul 2001 06:00:00 GMT'); header('Last-Modified: '.gmdate('D, d M Y H:i:s').' GMT'); header('Cache-Control: no-store, no-cache, must-revalidate'); header('Cache-Control: post-check=0, pre-check=0'); header('Pragma: no-cache');

Queda bastante claro no?

Segundo obstáculo: filtro anti-spam

Esta me costó bastante ya que fue difícil de detectar y sobretodo de reproducir. Sucede que tchile carga predeterminadamente un archivo .php que no sé qué hace pero tengo entendido que filtra un poco el spam. Este archivo se carga mediante la directiva auto_prepend_file de PHP y afortunadamente se puede sobre-escribir mediante .htaccess (Por lo menos en los servidores que me han tocado se puede).
Para sobre-escribir este filtro de spam, basta colocar en su .htaccess:

php_value auto_prepend_file none

Con esas dos cosas (por mientras) estarán más que bien en tchile. Si tienen otros tips, no olviden compartirlas en los comentarios!

Revisión de RUT con Javascript y PHP (Revisited)

unreal4u — Wed, 22 Sep 2010 03:24:42 +0000

Sí, es cierto, ya existe un post al respecto. Pero estoy viendo en Google Analytics que todo lo relacionado con el RUT es uno de los términos más buscados para la página, así que aprovecho de pegarle una revisión a ese post que ya tiene un poco más de 6 meses, así que bienvenido a la revisión del RUT como debería haber sido.

Como ese título siempre me ha llamado bastante la atención, es que le daré un enfoque bastante especial a que así sea. Este artículo estará separado en 3 partes: la primera, una explicación teórica sobre qué es el RUT y cuál es su función. La segunda, el algoritmo en JavaScript y el tercero, el algoritmo en PHP, obviamente estas últimas dos han sido revisados, actualizados y mejorados con respecto a su primera versión, desde la llamada inicial que se hace a la función, pasando por expresiones regulares y la detección automática del tipo de identificador: RUT o RUN.

Barniz teórico

En Chile, comúnmente se le denomina RUT tanto al RUT (Rol Único Tributario) como al RUN (Rol Único Nacional). La diferencia está en que el primero es un identificador de empresas mientras que el segundo sólo es para personas naturales. En este artículo, me referiré indistintamente a RUT o RUN.

Bueno, este número que consiste en un número de 1.000.000 a 99.999.999 es un identificador único a cada persona o empresa en Chile. Sé que también existe RUT en Argentina pero como no lo conozco (aunque tengo entendido que el algoritmo es bastante parecido) tocaré sólo el RUT chileno.
Además de esto, también se le une un dígito verificador que va de 0 a 9, más la letra K (representando 11), que no es nada más que una operación matemática basada en el número en sí para filtrar un poco que el número sea correcto.

Por lo tanto, este número, con la debida importancia que tiene, ha sido convertido casi en un estándar para la informática: un número único por persona, con límites conocidos, un checksum conocido y que se puede guardar fácilmente en una base de datos es lo único que una persona necesita para implementar el famoso RUT o RUN en su aplicación.

Sin embargo, siendo un número de millones, tenemos que existe una secuencia de 7 dígitos como mínimo y 12 como máximo que tiene que ingresar el usuario: tierra fértil para que el usuario se equivoque sin darse cuenta, más aún tratándose de una combinación de dígitos y signos de puntuación, y si queremos una base de datos que sea consistente... pues no podemos darnos el lujo de dejar que el usuario ingrese cualquier cosa.

Para esto, nació obviamente el último dígito de la secuencia, separada por una raya para distinguirlo, que lo que hace es revisar que el RUT ingresado corresponde a un número válido, el cual; mediante un algoritmo; se puede verificar (Y de ahí el nombre "Dígito Verificador").

En la práctica: JavaScript

Sin mayores secretos, la que más modificaciones sufrió fue la versión de Javascript, ya que se quitaron muchas partes que estaban redundantes y se resolvió que sólo iba a devolver un verdadero o falso. Si desean en cambio que retorne un número de error, pues con el código de PHP podrán modificar el de Javascript.

function verifica_rut(c){ var r=false,d=c.value,t=d.replace(/\b[^0-9kK]+\b/g,''); if(t.length==8){t=0+t;}; if(t.length==9){ var a=t.substring(t.length-1,-1),b=t.charAt(t.length-1); if(b=='k'){b='K'}; if(!isNaN(a)){ var s=0,m=2,x='0',e=0; for(var i=a.length-1;i>=0;i--){ s=s+a.charAt(i)*m; if(m==7){m=2;} else{m++;}; } var y=s%11; if(y==1){x='K';} else{ if(y==0){x='0';} else{e=11-y;x=e+'';}; }; if(x==b){r=true;c.value=a.substring(0,2)+'.'+a.substring(2,5)+'.'+a.substring(5,8)+'-'+b}; } } return r; }

y minificado:
function verifica_rut(c){var r=false,d=c.value,t=d.replace(/\b[^0-9kK]+\b/g,'');if(t.length==8){t=0+t;};if(t.length==9){var a=t.substring(t.length-1,-1),b=t.charAt(t.length-1);if(b=='k'){b='K'};if(!isNaN(a)){var s=0,m=2,x='0',e=0;for(var i=a.length-1;i>=0;i--){s=s+a.charAt(i)*m;if(m==7){m=2;}else{m++;};}var y=s%11;if(y==1){x='K';}else{if(y==0){x='0';}else{e=11-y;x=e+'';};};if(x==b){r=true;c.value=a.substring(0,2)+'.'+a.substring(2,5)+'.'+a.substring(5,8)+'-'+b};}}return r;};

Código en PHP

Aunque sufrió menos cambios que su simil en Javascript, tuvo una modificación bastante grande que fue el empleo de expresiones regulares para eliminar cualquier caracter que no deba ir en un RUT o RUN: de esa forma, se elimina cualquier caracter que no sea del 0 al 9, o la letra k (mayúscula o minúscula).

function verifica_RUT($rut='') { $sep = array(); $multi = 2; $suma = 0; if (empty($rut)) return 1; $tmpRUT = preg_replace('/[^0-9kK]/','',$rut); if (strlen($tmpRUT) == 8 ) $tmpRUT = '0'.$tmpRUT; if (strlen($tmpRUT) != 9) return 2; $sep['rut'] = substr($tmpRUT,0,8); $sep['dv'] = substr($tmpRUT, -1); if ($sep['dv'] == 'k') $sep['dv'] = 'K'; if (!is_numeric($sep['rut'])) return 3; if (empty($sep['rut']) OR $sep['dv'] == '') return 4; for ($i=strlen($sep['rut']) - 1; $i >= 0; $i--) { $suma = $suma + $sep['rut'][$i] * $multi; if ($multi == 7) $multi = 2; else $multi++; } $resto = $suma % 11; if ($resto == 1) $sep['dvt'] = 'K'; else { if ($resto == 0) $sep['dvt'] = '0'; else $sep['dvt'] = 11 - $resto; } if ($sep['dvt'] != $sep['dv']) return 5; return 0; }

Uniendo todos los cabos sueltos

Por supuesto que el ejemplo completo que incluye revisión (y formateo de RUT) en Javascript como en PHP es algo que no podía faltar:

= 0; $i--) { $suma = $suma + $sep['rut'][$i] * $multi; if ($multi == 7) $multi = 2; else $multi++; } $resto = $suma % 11; if ($resto == 1) $sep['dvt'] = 'K'; else { if ($resto == 0) $sep['dvt'] = '0'; else $sep['dvt'] = 11 - $resto; } if ($sep['dvt'] != $sep['dv']) return 5; return 0; } ?>Verificar RUT

Y eso sería todo amigos

Búsqueda de PHP.net en Firefox y trucos de vim

unreal4u — Thu, 19 Aug 2010 14:24:06 +0000

Hoy me di cuenta de algo que no me había dado cuenta. (duuuh)
Siempre, cuando necesitaba buscar alguna función en PHP.net, hacía la típica: iba a Google, tipeaba el nombre de la función, ubicaba PHP.net y hacía click.
Bueno, como casi todos los grandes descubrimientos de la humanidad, estaba en la portada de PHP.net y por accidente hice clic donde no debía. Descubrí esto:

Sin embargo, el verdadero potencial de este post está por verse, veamos algunos comandos semi-avanzados de vim que nos hará la vida mucho más fácil al trabajar con este editor.

Lo primero, (y más importante) a mi gusto, es instalar el manual de PHP en vim. Para esto, debemos tener instalado man y pear. De ahí, se procede a la instalación del manual.

En CentOS, todo esto se haría como:

# yum install php-pear man # pear install doc.php.net/pman

Y estaríamos con el 80% de la pega adelantada ya. Lo más importante, sin embargo, viene ahora.

Debemos, primero que nada, abrir el archivo ~/.vimrc. Si no existe, lo creamos. En ella, podemos configurar a nuestro gusto total vim, incluyendo opciones tan avanzadas como agrupar código (en una sola línea), poner el número de línea del código o consultar el manual de PHP con una tecla mientras estamos en la función. (Muy al estilo man).

Esta es mi configuración actual de vim:

set tabstop=2 set autoindent set incsearch set number set keywordprg=pman autocmd FileType php let php_folding=1 au BufWinLeave * mkview au BufWinEnter * silent loadview

Explicaré cada línea:
set tabstop=2: Esto nos permite que, cuando apretemos tab, inserte espacios en vez de un tab. La cantidad de espacios es definida después del signo igual.
set autoindent: Esta muy útil función permite que vim siga las reglas de indentación que tiene el archivo. Muy útil.
set incsearch: permite que, muy al estilo búsqueda rápida de Firefox, se vaya ubicando automáticamente el cursor en cuanto estemos buscando alguna frase.
set number: le pone número a las líneas.
set keywordprg=pman: esta línea hace que integremos pman con vim, para que de esta manera, al apretar "K" (k mayúscula) sobre alguna función en específico aparezca el manual.
El resto: Activa la agrupación de código. La primera línea inicia la característica en sí, mientras que las dos siguientes guardan y cargan automáticamente las agrupaciones respectivamente.
Se debe utilizar en conjunto con algunos comandos:

:20,40 fo
Para agrupar de la línea 20 a la 40.

zfa}
Para agrupar de aquí a la próxima llave, aunque ojo: se debe estar posicionado sobre la llave que abre!

zd
Para eliminar el fold actual

zm
Para refoldear todos los folds anteriores.

Para más comandos útiles, visitar la tercera fuente.

Hay bastantes más consejos para vim, pero no todos me funcionaron. Una de las más populares que he visto dando vueltas por internet es activar la vista de código HTML o queries dentro de los string, pero no me funcionaron. Tampoco me funcionó desactivar los tags cortos, así que ojo con eso.

Fuentes:
PHPSLACKER
bjori doesn't blog
Linux.com