"Trackeando" iframes en DFP

Llevaba un tiempo pensando cómo se podía hacer esto, es decir, que un anuncio tipo "iframe" pudiese contener en sus URLs el código de seguimiento de Google DFP.

Antecedentes:
Supongamos que tenemos una "creatividad" (que poco me gusta este término) del tipo "terceros" en nuestra cuenta de DFP. El código corresponde a un iframe que sale de nuestro servidor:

http://miservidor.com/anuncios/anuncio1

Y la página http://miservidor.com/anuncios/anuncio1 devuelve el siguiente HTML:





Si creamos en DFP el banner del tipo "terceros" y ponemos el iframe, DFP podrá controlar las impresiones del banner, pero no los clicks, puesto que en ningún sitio hemos insertado la macro correspondiente, típicamente %%CLICK_URL_ESC%%



La solución:

Al llamar al iframe, añadimos como parámetro la macro, esto es:

<iframe src="http://miservidor.com/anuncios/anuncio1?macro=%%CLICK_URL_ESC%%">

Cuando DFP lance una impresión de nuestro banner, la macro será sustituida por el correspondiente código de seguimiento y desde el script que genera el banner, capturar el la url de seguimiento de DFP.

Supongamos que trabajamos con PHP, la modificación sería la siguiente en la página http://miservidor.com/anuncios/anuncio1:

<?php
$enlace = urldecode($_GET['macro']);
?>

<a target="_top" href="http://miservidor.com/articulos/articulo1">


Y eso es todo. En enlace que sale en el iframe ahora tendrá el código de seguimiento de Google DFP, contabilizará el click y redigirá al enlace final, http://miservidor.com/articulos/articulo1

Por supuesto, hay que tomar todas las medidas de seguridad oportunas para evitar problemas (comprobar y sanear el parámetro que llega, etc).

phpMemcachedAdmin

He descubierto hace poco esta magnífica herramienta de administración vía web para Memcache.

Tiene un montón de características interesantes: estadísticas de todo tipo, búsqueda de claves, consola de comandos. La instalación y configuración es trivial.

Eso sí, seguridad, ninguna. No es una herramienta que deba estar expuesta, sólo debería utlizarse desde el "backend".

Utilizando Memcache en Symfony 1.4

Llevaba tiempo buscando un plugin para symfony 1.4 que permitiese cachear en Memcache en vez de en ficheros.

Encontré este, sfMemcachePlugin, pero parece que no está mantenido y no me he atrevido a instalarlo.

En mi aplicación sólo necesitaba cachear los resultados de una consulta especialmente pesada (es una cartelera de cine, la consulta consiste en cruzar todas las películas con todas las poblaciones donde hay cines que la tengan en cartelera).

Mi solución ha sido un tanto rudimentaria pero funciona muy bien:

Primero defino un método estático en una clase "Utilidades" que me devuelve un objeto memcache:

class Utilidades {
    public static function getMemcache() {
        $objMemcache = new Memcache;
        $objMemcache->addServer('servidor1',11211);
        $objMemcache->addServer('servidor2',11211);
        /* etc */
        return $objMemcache;
    }
}

Después, en la clase que hereda de Doctrine_Table, defino el método que devuelve los resultados cacheados:

class FooTable extends Doctrine_Table {
    public static function getConsultaCacheada() {    
        $clave = "FooTable-getConsultaCacheada";
        $timeout = 3600;
        $memcache = Utilidades::getMemcache();
        $datos = $memcache->get($clave);
        if(!$datos) {
            $query = Doctrine_Query::create()->from('Tabla a')->where('...');
            $datos = $query->fetchArray();
            $objMemcache->set($clave, $datos, null, $timeout);
        }
        return $datos;
    }
}

Super sencillo y funcional ;-)

Haría falta código adicional para controlar errores, etc, pero la idea básica es ésta. Se puede añadir algún parámetro al método como public static function getConsultaCacheada($nocache=false) para poder hacer consultas "frescas" sin tirar de Memcache si es necesario.

Más información del uso de Memcache en PHP en php.net/manual/en/book.memcache.php

Tira nº 76: usuaria avanzada

A ver cuánto tardan en sacar algo así. Sacar algo relativo a la teoría de conjuntos debe ser una tentación muy fuerte :-)

Tira nº 75: tormenta

Las tormentas veraniegas son frecuentes...

Recuperemos el denostado tag "blink"

Con lo bonito que era el parpadeo de las webs que había en Geocities...

<html>
<head>
<title>¡¡¡Blink!!!</title>
http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js

function blinkear() {
var blink = $('blink');
    if (blink) blink.toggle();
}
$(document).ready(function () {
    setInterval(blinkear, 700);
});

<style>
blink {color: lime; font-size: 22px;
       font-family: "Comic Sans MS";
       font-weight: bold;}
</style>
</head>
<body>
<blink>El parpadeo es divertido...</blink>
</body>
</html>

 

Tira nº 74: despido procedente

Gestor de tareas

Busco desesperadamente un programa para gestionar tareas que me permita hacer algo como esto:



Sería muy útil :-)

Tira nº 73: bienvenida

El juguetito existe: http://www.youtube.com/watch?v=PcrXDPNmogk#t=0m16s

Tira nº 72: en la feria de Retroinformática

Nuestros dos amigos se creen muy ilustres, pero no...

Tira nº 71: resurrección

No digo nada, que luego siempre me pasa lo mismo, subo una tira y se me vuelven a pasar los meses hasta la siguiente.

A ver qué nuevas aventuras les pasan a estos dos dinosaurios...

Limpiando duplicados en iTunes

Supongo que le habrá pasado a más gente, vas importando música a la biblioteca de iTunes y de vez en cuando aparecen duplicados. Borrarlos a mano es muy tedioso, así que aquí está el script que los borra físicamente de la biblioteca.

La idea básica es que cuando iTunes duplica un archivo, lo hace añadiendo 1 al nombre del fichero. Este script en Python los detecta (y si quieres, los elimina):

import os
def f(arg,dirname,names):
  print "Reading directory " + dirname
  for n in names:
    try:
      if n[-6:] == ' 1.mp3':
	fich = dirname + '/' + n
	print "Removing " + fich
	try:
	  pass
	  # Uncomment the line above (under your responsability)
	  #os.remove(fich)
	except Exception as (errno, strerror):
	  print strerror
    except Exception:
      pass

startpoint = os.path.expanduser('~') + '/Music/iTunes/iTunes Music'
os.path.walk(startpoint, f, None)

Grooveshark, app para iPhone y mp3 cifrados

Recientemente he adquirido una cuenta VIP en Grooveshark. Estoy encantado.

Tienen una aplicación para distintos terminales móviles y me he descargado la del iPhone (requiere iPhone con "jailbreak"). La aplicación tiene un "modo offline" muy útil para escuchar música sin tirar de la conexión de datos o Wifi.

El caso es que quería recuperar algunos de estos mp3 para escucharlos en el "netbook" (la aplicación de escritorio, basada en AIR) no tiene un modo offline.

Así que, cacharreando un poco, encontré dónde guardaba la aplicación Grooveshark para iPhone sus archivos offline. Se necesita el iPhone, con "jailbreak", por supuesto y la utilidad ifuse (en Ubuntu sólo hay que instalar el paquete correspondiente).

1. Montamos el iPhone en modo "root" en el directorio que nos apetezca, por ejemplo:
   

   ifuse --root ~/iphone

   
   


2. La aplicación Grooveshark guarda los archivos offline en este directorio:
   

   /private/var/mobile/Library/Grooveshark/offline

   
   


3. Veremos un montón de ficheros .mp3 en este directorio, pero tienen un problema: no se pueden escuchar directamente, de alguna forma están manipulados para que no sean reproducibles.


4. Nos los copiamos a nuestro ordenador. Veremos que no son reconocidos como ficheros .mp3:
   

   yo@ordenador:~$ file ~/iPhone/private/var/mobile/Library/Grooveshark/offline/27935561.mp3
   ~/iPhone/private/var/mobile/Library/Grooveshark/offline/27935561.mp3: data

   
   


5. Copiamos este script (lo encontré en un foro): http://pastebin.no/32i1
   Lo guardamos y podemos ejecutar:
   

   python script-que-descifra.py FICHERO_MP3_CIFRADO.mp3 FICHERO_MP3_DESCIFRADO.mp3

   
   Y nos queda un fichero .mp3 con un nombre no muy identificativo pero con todos los tags ID3 bien puestos.

ebook vs papel (o 6 meses con un Kindle)

Tengo un libro electrónico (un Kindle 3) desde hace unos 6 meses, y le he dado un uso bastante intensivo. Llega el momento de sacar algunas conclusiones respecto al aparatito.

Generalmente se suelen poner ventajas de uno frente al otro, pero no me vale esta comparación, prefiero comparar según el tipo de lectura que estoy haciendo. Suelo leer tres tipos de libros: técnicos o manuales, novelas y libros de partituras (tipo Real Book).

Libros técnicos, manuales o "libros de texto"

Por mi profesión (desarrollador web) tengo que leer mucha documentación, aparte estoy estudiando una ingeniería en la UNED.
Decididamente, el libro electrónico no es cómodo para mí en este contexto. Aunque mi modelo permite hacer anotaciones, no hay nada como el subrayado con lápiz o las notas al margen tradicionales.
En un volumen de papel se ojea y rebusca con mucha facilidad y rapidez, con el "ebook" no me termino de apañar. He comprado alguno en formato electrónico y no me ha convencido, la verdad. También he intentado estudiar alguna asignatura en el "ebook" y no me siento cómodo, sigo muy aferrado a la costumbre de ir leyendo el libro, marcándolo y escribiendo en el cuaderno. A lo mejor es que ya estoy talludito ;-)

Novelas

En mi opinión, en este tipo de libros, el "ebook" tiene todas las de ganar. Puedes tener colecciones enteras en un cacharrito muy reducido, se lee muy bien, puedes poner marcadores en los pasajes más interesantes y en algunas plataformas (como la de Amazon), sincronizar el punto de lectura entre distintos dispositivos: aunque la pantalla del móvil no sea el dispositivo más idóneo para leer mucho rato, está muy bien poder retomar la lectura en la consulta del médico mientras esperas y seguir luego en casa donde lo dejaste en el móvil :)

Por supuesto, leer novelas en papel tiene su encanto y me gusta, pero el "ebook" es infinitamente más práctico ("El Conde de Montecristo" es un buen tocho para ir llevándolo a todas partes).





Partituras

Aquí si que me he llevado un buen chasco con el "ebook". Creía que podría prescindir al fin de los Real Book (son unos libracos de alrededor de 500 páginas), pero no puede ser: primero, mi "ebook" tiene la pantalla muy pequeña (6''), las notas casi no se ven -aunque en un modelo que tenga la pantalla más grande, tipo Kindle DX o iPad se ven bastante bien-; segundo, si ojear un libro técnico es lento, uno de partituras lo es más (suelen ser PDFs compuestos por imágenes, del orden de las decenas de megas).
Además, hacer una anotación rápida en un ensayo de un símbolo musical, cambiar notas, etc, es imposible (aunque esto ya lo sabía).

En este aspecto, tendré que seguir haciendo lo que hasta ahora: imprimir en hojas sueltas los temas que estoy montando si no quiero cargar con el volumen enterito.

Conclusión

En mi opinión, vamos a tener libros en papel mucho tiempo todavía... Es un soporte bastante fiable, duradero y fácilmente editable. Eso sí, los libros electrónicos para determinados tipos de lectura son una maravilla. A ver si las editoras se ponen las pilas, amplían catálogo y ponen precios razonables. Amazon está a la vuelta de la esquina y cada vez tiene más títulos en castellano a buen precio.

Fallos tontos con INSERT en SQL

El otro día tuve que arreglar un "bug" que yo mismo había causado. En un momento dado, se guardaba un valor en una tabla de N campos. Mi "query" era la siguiente:

INSERT INTO miTabla VALUES ('valor1', 'valor2', 'valor3');

En un momento dato, se hizo necesario añadir un campo más a esta tabla. Inocente de mí, pensé lo siguiente: "si añado el campo con un valor por defecto, no se estropeará ninguna "query", ya que, aunque la consulta no mencione el campo, éste ya tiene un valor por defecto".
Craso error.
La "query" anterior fallaba (estoy utilizando MySQL), ya que se encontraba con un campo más de lo esperado.
Conclusión: hay que escribir explícitamente todos los campos en los INSERT. Nunca se sabe qué cambiará.

INSERT INTO miTabla (campo1, campo2, campo3) VALUES ('valor1', 'valor2', 'valor3');