Algo pasó durante el fin de semana que de pronto al buscar por Google Hell aparezco en los primeros lugares… así que aprovechando el impulso, voy a explicar un poco mejor de qué se trata, cómo evitarlo y cómo salir de ella… si tienes suerte. (Y paciencia).

Google Hell (traducido: el infierno de Google o GInfierno) fue un término acuñado porque de pronto el gigante buscador simplemente puede decidir dejarnos fuera de su índice principal, relegando nuestras propias páginas a meras búsquedas del tipo “site:misitio.com busqueda”, algo que se conoce como el índice suplementario. También existe la posibilidad (menor, pero posibilidad a fin y a cabo) de que nos banee y nos ponga en un blacklist. Por este hecho, es probable que de pasar a ser siempre los número 1 en casi cualquier búsqueda, pasemos directamente a la página 300, con suerte: aquella última página que nadie visitará y por lo tanto, reducirá las visitas en un (en mi caso) casi 65%. Auch.

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.

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

<texto><[CDATA[<p>Hola mundo</p>]]></texto>
// y no así:
<texto>&gt;p&lt;Hola mundo&gt;/p&lt;</texto>

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.

Aunque por lo general ningún servidor me da problemas, la máquina que aloja este blog está dando un poco de jugo. El proceso del Apache tiene la mala costumbre de tomarse el 100% del procesador por algunos segundos (hasta 30) y durante ese lapso de tiempo simplemente no aparece nada en el cliente. Sin embargo, ese error es tan vago que no da para nada más. En los logs tampoco aparece nada inusual, así que simplemente aplicaré regla de oro en la informática: ir probando para ver si puedo replicar el error. (Que manera tan elegante de decir: “prueba y error”).

Antes que todo, quisiera pedirle disculpas a un cierto amigo que posteó un comentario, akismet lo tomó como spam y sin querer queriendo, me confundí de botón y lo borré de la base de datos en vez de aprobarlo. A la rápida, alcancé a leer algo de https y redirección (también tenía un link hacia un más información en X sitio), pero no me fijé a qué post correspondía. Así que si no es mucha molestia, se podría postear de nuevo? :D Prometo fijarme mejor esta vez.

En fin, el post de hoy se trata de nada más ni nada menos que svn. Odiado por muchos (Basta ver este video de Linus Torvalds donde básicamente dice que svn está mal desde su base) y amado por otro puñado de desarrolladores, es bastante fácil de ocupar y tiene opciones bien poderosas una vez que se aprende a ocupar bien. Y para eso es este post :)

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.

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.

Este post será cortito y es sólo para que no tenga que andar buscando dentro de logs algo que aplico sólo muy a veces: se trata de querer proteger un directorio predeterminado mediante htpasswd para que de esta manera, necesitemos de autentificación antes de poder continuar escudriñando en la página.

El método es bastante simple: basta crear un .htaccess y un .htpasswd, el segundo ojalá fuera del directorio público. De todas formas, apache predeterminadamente manda un 403 (Prohibido) a todos los archivos que empiezan con .ht (dato rosa, con expresiones regulares sería “^.ht”) pero nunca está demás poner una capita adicional a la seguridad del server. Más después del salto.