Script Caza Unfollowers de Twitter

Las reacciones ante un unfollow en Twitter suelen ser diversas, desde la acción recíproca inmediata (cosa que no logro entender ¿has dejado de ver el telediario porque el presentador no se dirija a ti en persona? pues eso…) hasta la más absoluta indeferencia. A mi más bien me mueve la curiosidad, saber si ha sido la posible reacción ante un tuit concreto, el perfil de la persona que deja de seguirme, etc…

Aquí os traigo un pequeño script que he hecho para enterarme de esto. Sé que hay por ahi muchos servicios que hacen lo mismo, los he probado y todos me han parecido una chusta, publicidad, desfase en la notificación y en general nada que cumpla bien algo tan simple como esto. Por eso he acabado tirando unas líneas de código para tenerlo en mi propio servidor y hacer exáctamente lo que espero, que es muy sencillo: recibir un email cada vez que alguien deje de seguirme en Twitter. A continuación explico algunos detalles de esta mini aplicación que podéis descargar desde github.

Continuar leyendo – Script Caza Unfollowers de Twitter »

Conflicto de herencia en htaccess entre Rewrite y Auth

Atención al titulo, soy un hacha jugando con keywords para atraer a todo tipo de audiencia al blog… y no, no se ha muerto Apache y los módulos se pelean por la pasta… en fin, al turrón. Pongamos que tenemos una web http://www.pepe.com, que en el servidor corresponde al path /home/web/pepe, y un subdirectorio http://www.pepe.com/admin, cuya ruta es /home/web/pepe/admin.

En mi caso concreto pepe.com es un dominio antiguo, y quiero que toda referencia a él acabe en el nuevo, digamos paco.com. Para ello utilizo un htaccess que hace una redirección 301 a lo bruto:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)$ http://www.paco.com [R=301,L]

Éste es mi problema concreto, pero por ejemplo es también muy común en frameworks y CMS hacer una redirección general de todas las peticiones a un único fichero. Vamos, que aquí lo importante es la reescritura general.

Ahora lo que quiero es proteger con contraseña el acceso a mi administración, por lo que utilizo otro htaccess con el contenido estándar para ésto:

# colocado en /home/web/pepe/admin/.htaccess
AuthType Basic
AuthUserFile /home/web/pepe/admin/.htpasswd
AuthName "Acceso Administrador"
Require valid-user

Y como no podía ser de otra forma el invento no funciona. Cuando intento acceder a http://www.pepe.com/admin me redirige a http://www.paco.com, luego el primer cambio es meter una excepción para que no aplique la regla de reescritura para la URL que nos interesa. Lo podemos hacer en el htaccess principal con una condición:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/admin/?RewriteRule ^(.*)$ http://www.paco.com [R=301,L]

O si no necesitamos de ninguna reescritura en el directorio hijo podemos directamente desactivar el engine:

# colocado en /home/web/pepe/admin/.htaccess
RewriteEngine offAuthType Basic
AuthUserFile /home/web/pepe/admin/.htpasswd
AuthName "Acceso Administrador"
Require valid-user

Cojonudo, pero sigue haciendo la redirección. Primera comida de cabeza importante: comento todas las reglas de reescritura y sigue redirigiendo ¿? resulta que Firefox cachea las redirecciones (al menos las 301), así que ya puedes darle a F5 y estar correctas las reglas, que no te enterarás si no borras la caché del navegador, eso o utilizar Explorer (no lo he probado en el resto).

Descartado el navegador, ésto sigue sin rular. Utilizando el imprescindible HttpFox y Google descubro que la autenticación básica de Apache que queremos usar manda una cabecera 401 Unauthorized, que el navegador recibe y es cuando muestra el cuadro de usuario/contraseña. Segunda comida de cabeza importante: el servidor está buscando un mensaje de error personalizado para el 401 (en una directiva ErrorDocument), que no encuentra y por tanto lanza, adicionalmente, un 404. Y resulta que, no me preguntes por qué, este último error pasa por la reescritura general y es lo que está provocando la redirección. Acojonante. La solución es definir dicho ErrorDocument en nuestro htaccess:

# colocado en /home/web/pepe/.htaccess
Options +FollowSymlinks
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/admin/?
RewriteRule ^(.*)$ http://www.paco.com [R=301,L]
ErrorDocument 401 "Acceso restringido"

¡Aparece el cuadro para meter usuario/contraseña! joder, ha costado.

Historias para no dormir: perder un iPhone

No me ha pasado, pero sí: yo salgo a la calle con el iPhone en el bolsillo ACOJONADO.

Antaño, cuando perdías un PC era poco menos que una hecatombe (y una especie de catarsis cuando lo asumías): fotos, música, documentos, toneladas de películas… hoy en día Internet lo ha cambiado todo, y al menos los hardcore users (a los que siempre asocio con el iPhone, al menos con el uso intenso del iPhone al que aquí me refiero) ya guardan gran parte de esa información en la nube.

Éste es uno de los ingredientes de la tragedia. El otro es la miniaturización del hardware y el poder llevar ahora un mini ordenador en el bolsillo, dispositivos que permiten acceder a la nube desde cualquier sitio.

En definitiva: cacharro + nube + pérdida/robo = El Horror

Y para ilustrar mi pavor, una captura de la pantalla principal de mi iPhone, así que el desgraciao que lo encontrara/robara tendría acceso a:

• Contactos: tener el número de mi madre y llamarla para burlarse de lo mandril que es su hijo es todo uno.
• Calendario: ver dónde y a qué hora tendría una cita, podría venir a robarme la cartera también.
• Fotos: ni te cuento, de hecho se me están poniendo los pelos como escarpias de pensarlo, voy a borrar algunas…
• MoneyBook: app para llevar un control de gastos personales, aquí la verdad más que nada le entraría la risa…
• Remember the milk: app para el control de tareas, lo mismo, “comprar calcetines de algodón” es algo íntimo que no debe ser compartido.
• MobileRSS: lee tus propios feeds, desgraciao!
• Tiempo: que pueda consultar el tiempo que hace en Elche desde MI telefóno no es justo.
• Twitter: aquí traspasamos la delgada línea roja: redes sociales. Empezar a seguir a Enrique Dans me parece un ejemplo bastante cruel de puteo con mi cuenta…
• Facebook: no te digo ná y te lo digo tó!
• Tumblr: aquí sí que me cabrearía, mi tumblr es ahora mismo la joya de lo corona, pff…
• LinkedIn: supongo que arruinar mi carrera profesional con un “mecagontosmisjefes” es un buen puteo.
• Evernote: aquí hay un poco de todo: facturas, apuntes, contraseñas, etc… vamos, el Dorado del desgraciao.
• Dropbox: pues lo mismo, si Evernote era el Dorado, éste es el Santo Grial.
• Mensajes: y además ordenaditos por conversación, un puto lujo oche!
• Mail: acceso directo y rápido a todas mis cuentas de email, el único límite es la imaginación!

Bueno, creo que el concepto ha quedado claro. Y ésta es una página de 4 (y lo restauré hace poco…) de aplicaciones, telita!

Y sí, claro que tengo activo el bloqueo con código, pero sin saber ni papa de estas cosas, pondría la mano en el fuego a que hay alguna forma sencilla de saltarse esta protección… lo dicho, tal es el acojono que me estuve planteando pagar por una cuenta de MobileMe únicamente por el borrado a distancia, pero no, he optado por la opción gitaner: un móvil de los que darían con los cereales que no tenga ni WAP para llevar en determinadas salidas (principalmente cualquiera que implique noche). Mi iPhone es mucho iPhone.

Scroll infinito con jQuery

También conocido como endless scrolling, endless pageless, paginación sin páginas, etc… es un patrón de interfaz de usuario del que se viene hablando desde hace unos años, aunque es últimamente cuando parece que lo veo implementado en cada vez más sitios.

El ejemplo por antonomasia es por supuesto el de Google Reader, pero hay muchos más: Facebook (fijaros que lo hace una vez cuando vas a mitad de página), Digg, Bing, Vimeo, Dropular….

Básicamente consiste en cargar más contenido dinámicamente conforme te acercas al final de la página, de forma que la navegación por el mismo no queda interrumpida en ningún momento. Viene a ser un sustitutivo de la paginación tradicional.

Luego comentaré los pros y contras que pienso tiene esta técnica. Antes contar cómo lo he implementado en mi tumblr, micro Usuario de Internet, algo que llevaba bastante tiempo queriendo hacer y que sin duda opino le va como anillo al dedo.

Aunque en principio tenía intención de remangarme, encontré un plugin, de-pagify, que lo implementa de forma muy flexible y aprovechando parte de la magia de jQuery. Utilizar un framework de javascript simplifica considerablemente la codificación del método, que de otra forma sería bastante más laboriosa, sobre todo el paso de procesar el contenido para pintarlo en pantalla.

En la página del plugin viene todo explicado muy claramente, sólo destacar dos cosas:

• Hay 4 formas de lanzar el evento para traerse más contenido. Se configura con el párametro trigger, y puede ser cuando se llegue a un % de altura de la página, a una altura determinada (pixels), cuando se vea un determinado elemento de la página (mi elección) o incluso dependiendo de la salida de una función propia. La flexibilidad es máxima.
• Como he comentado, utilizar jQuery ahorra mucho código, y una de las perlas que más me ha gustado es la siguiente línea:

  // Format url as "?page=1 div#wrapper div.post"
  var url = [next.attr('href'), options.container, options.filter].join(' ');

  El método de ajax load, que es con el que nos vamos a traer el contenido de la siguiente página para pintarlo dinámicamente, permite especificar la URL con selectores separados por espacios, de manera que podemos controlar qué elementos, qué HTML al fin y al cabo, queremos que se cargue en la capa que eligamos. Ésto nos ahorra de una tacada tener que hacer alguna modificación en el código de la aplicación (se van a ir pidiendo por ajax sucesivas páginas como si la navegación fuera la clásica) y tener que procesar el HTML que recibimos (se pinta tal cual porque ya viene filtrado con el contenido, lo único que he tenido que modificar de la página es un poco la maquetación).

En definitiva, y en mi opinión:

PROS

• Experiencia de usuario: no tengo la menor duda de que, para cierto tipo de webs y, sobre todo, de contenido, el eliminar la paginación supone una mejora muy significativa en la forma de navegar por el sitio, comportándose de la forma natural en la que uno esperaría moverse por él.
• Consumo: cuando desaparece el punto final (pie de página y paginación) pasa a ser un comportamiento natural el hacer scroll indefinidamente y por tanto seguir consumiendo el contenido de manera indefinida.

CONTRAS

• Experiencia de usuario: y no es una contradicción, la nueva forma de navegación puede confundir a muchos usuarios menos duchos en esto de Internet, acostumbrados a los puntos de ruptura (paginación), a saber por qué página del libro van y a una estructura de web más convencional.
• Implementación: no es tema trivial, ya no técnicamente, sino desde el punto de vista de la usabilidad. Por ejemplo está muy unido al dispositivo utilizado: con la rueda del ratón todo es maravilloso, con el teclado o arrastrando la barra de scroll ya pueden darse saltos incómodos. La norma aquí es que sea prácticamente imperceptible para el usuario lo que se está cociendo de fondo (aquí tengo que mejorar mi implementación).
• Monetización: en sitios que se ganan las habichuelas con la publicidad puede suponer un problema la ubicación de los bloques de anuncios. Un esquema típico de jumbobanner arriba, roba a la derecha y Adsense bajo el contenido queda bastante desvirtuado con esta navegación. Lo mismo con páginas vistas (solucionable con una buena semilla).

Internacionalización con Smarty

El temita de la internacionalización (i18n para los amigos) en una aplicación web puede dar para largo y tendido, yo voy a hablar aquí concretamente de la forma de guardar y utilizar las cadenas de texto del site en varios idiomas utilizando el framework de templates Smarty.

Hay muchas formas de hacerlo, se pueden encontrar varias alternativas en este post de best way to build a multi-language site with smarty, que empezó en el ¡2003! (el frenético ritmo que lleva la tecnología hace que no me crea nada que no sea de ayer…). Todas tienen sus ventajas e inconvenientes, y dado que no hay nada en el core de Smarty para ésto ni una solución popularmente aceptada como la estándar, cada uno debe analizar lo que necesita para su proyecto y tener unas preferencias subjetivas, que en mi caso son:

• Que no implique PHP: obviamente hay opciones mucho más sofisticadas, eficientes, etc… para solucionar el tema del i18n con programación (por ejemplo smarty-gettext), pero precisamente el uso de Smarty es para separar la lógica de la aplicación de la de presentación, y dado que considero que ésto es problema de front-end puro, yo quiero resolverlo únicamente con Smarty.
• Que sea sencillo y eficiente: con el tiempo me estoy conviertiendo en un talibán del código, en el sentido bueno (creo) de intentar que las cosas se hagan de la forma más clara posible (KISS power!) y que note un pinchazo en el corazón con cada ciclo de reloj que se consume en código prescindible.

Continuar leyendo – Internacionalización con Smarty »