Básicamente el User-Agent nos indica cual es el cliente que está realizando la petición. Si se trata de un navegador, de un robot, …  En principio esta cadena se envía en todas las cabeceras HTTP, sea el cliente que sea (aunque también podría omitirse).

Para obtener el “user-agent” en Google App Engine símplemente, desde cualquier método “get” o “post” que derive de webapp.RequestHandler podemos hacer:

self.request.headers['User-Agent']

Otra cosa bastante útil es averiguar la IP del cliente que nos está realizando la petición. Esto es más fácil aún:

self.request.remote_addr

La IP se suele utilizar para localizar geográficamente a la persona que está solicitando la página web.

Links relacionados:

• Geolocalización en Google App Engine
• Google App Engine > Python > The Request Class

browser, geolocation, user-anget

Quería realizar experimentos acerca de la longitud máxima con la que se puede hacer una petición con GET en los distintos navegadores, y al final el más restrictivo ha resultado ser el servidor.

Según las pruebas que he estado realizando, resulta que Google App Engine sólo hacepta URLs de hasta 2048 caracteres.

Por lo tanto, si vas a realizar una petición GET a tu aplicación en Google App Engine, asegurate de que tanto la dirección de la página, junto con los datos GET no supere los 2048 bytes.

experiment, gae, google app engine, url

Me resulta sorprendente que Google no ofrezca ningún servicio o método en Google App Engine para obtener la localización geográfica a partir de la IP. Es algo que ellos tienen más que resuelto, y no veo motivo por el cual no lo ofrezcan a los desarrolladores en la parte del servidor  (en la parte del cliente se puede usar google.loader.ClientLocation en javascript)

Por suerte, este es un problema que se puede resolver fácilmente de dos maneras distintas.

Solución 1: haciendo peticiones a otro servidor

Hacer peticiones HTTP a http://geoip.wtanaka.com/ y éste nos devolverá el código de país:

Por ejemplo para saber el país de la dirección 72.14.235.121 sólo habría que hacer una petición a http://geoip.wtanaka.com/cc/72.14.235.121

Para código sobre cómo hacer este tipo de peticiones, podeis echarle un vistazo a http://code.google.com/p/geo-ip-location/wiki/GoogleAppEngine

Solución 2: implementarlo en el propio servidor

A mi esta otra solución me gusta más. Se trata símplemente de bajarse la última versión de GeoIP.dat y usarla con la librería pygeoip.py

Luego es tan fácil como hacer:

def getCountryByIP (remote_addr):
  GEOIP = pygeoip.Database('GeoIP.dat')
  info = GEOIP.lookup(remote_addr)
  return info.country

Nótese que la librería no está pensada para hacer esto así, ya que cada vez que se llama a pygeoip.Database se carga el archivo entero a una cadena en memoria, y, en principio, a nosotros nos interesaría cargarlo sólo una única vez.

Por otra parte, en mi caso sólo me interesaba hacer un único lookup, así que cargar el archivo a memoria no tenía mucho sentido.

He actualizado la librería para permitir dos modos. El modo cargarlo a memoria (mejor si vas a hacer cientos de lookups), y el modo acceder directamente al archivo en disco (mejor si vas a hacer pocos lookups, ya que consume menos memoria y tarda igual o incluso menos).

Aquí os dejo el archivo pygeoip.py con mis cambios. Para usarlo he añadido la función disk_lookup:

pygeoip.disk_lookup (remote_addr)

Para hacer un único lookup va más rápido y consume infinitamente menos memoria.

Desde aquí quiero felicitar a David Wilson, el autor de esta librería, porque ha sido muy fácil implementar estos cambios (por supuesto le he mandado un e-mail, ahora es cosa suya incluir mis cambios o no hacerlo).

geoip, google app engine, Python

Las codificaciones de caracteres (character encoding) son la mayor patraña jamás inventada, gracias a dios se inventó Unicode, con sus variantes UTF-8 y UTF-32.

Para mi, UTF-8 es, y debería ser el estándar  para guardar o enviar cadenas de texto.

Los lenguajes de programación, python incluido, no deberían soportar otra cosa que no fuera UTF-8 o cadenas de bytes.  La verdad es que lo voy a dejar aquí, porque cada vez que pienso en este tema, me enciendo.

El caso es que el soporte de codificaciones de texto en Python me parece lo peor. ¿Por qué? Porque no es suficientemente inteligente para mezclar cosas, y lanza excepciones a la mínima.

Hasta hoy, usaba str.decode(‘utf-8′, ‘ignore’) donde str es la cadena que quiero convertir a UTF-8, pero ni siquiera esto me libraba de excepciones.

Hoy, buscando otra vez una solución, he encontrado la función force_unicode del frámework django. De momento, con las pruebas que he hecho, se lo come todo. Es perfecto.

Símplemente quería compartir esto:

def force_unicode(s, encoding='utf-8', errors='ignore'):
    """
    Returns a unicode object representing 's'. Treats bytestrings using the
    'encoding' codec.
    """
    import codecs
    if s is None:
      return ''

    try:
        if not isinstance(s, basestring,):
            if hasattr(s, '__unicode__'):
                s = unicode(s)
            else:
                try:
                    s = unicode(str(s), encoding, errors)
                except UnicodeEncodeError:
                    if not isinstance(s, Exception):
                        raise
                    # If we get to here, the caller has passed in an Exception
                    # subclass populated with non-ASCII data without special
                    # handling to display as a string. We need to handle this
                    # without raising a further exception. We do an
                    # approximation to what the Exception's standard str()
                    # output should be.
                    s = ' '.join([force_unicode(arg, encoding, errors) for arg in s])
        elif not isinstance(s, unicode):
            # Note: We use .decode() here, instead of unicode(s, encoding,
            # errors), so that if s is a SafeString, it ends up being a
            # SafeUnicode at the end.
            s = s.decode(encoding, errors)
    except UnicodeDecodeError, e:
        if not isinstance(s, Exception):
            raise UnicodeDecodeError (s, *e.args)
        else:
            # If we get to here, the caller has passed in an Exception
            # subclass populated with non-ASCII bytestring data without a
            # working unicode method. Try to handle this without raising a
            # further exception by individually forcing the exception args
            # to unicode.
            s = ' '.join([force_unicode(arg, encoding, errors) for arg in s])
    return s

Estoy convencido de que si tienes problemas con los strings en python, sabrás apreciar este código.

character encoding, django, force_unicode, unicode, utf-8

Me hacía falta un framework de javascript que fuese capaz de cambiar el CSS de los elementos, que fuese capaz de hacer peticiones AJAX,  capaz de cargar javascripts o CSS externos, capaz de añadir o cambiar HTML sobre la marcha, capaz de capturar eventos, capaz de realizar animaciones y capaz de evitar colisiones con otros frameworks o incluso con sigo mismo, y además, que fuera superligero y funcionara en IE6+, FF, Safari, Chrome y Opera.

Al final, después de cansarme de buscar y buscar, lo he programado yo, y en honor al blog, he decidido llamarlo manso framework. mansofk para los amigos.

Al final he conseguido meter toda esta funcionalidad en tan sólo 1.5KB.

Las funcionalidades principales son:

• Fácil renombrar el framework para evitar colisiones
• Soporta encadenamiento de llamadas
• Soporta la carga de componentes externos de forma dinámica
  • Soporta cargar CSS externos dinámicamente
  • Soporta cargar javascript externos dinámicamente
• Manipulaciones DOM sencillas
  • Seleccionar elementos por ID
  • Añadir elementos
  • Reemplazar elementos
• Manipular el estilo CSS de los elementos
  • Obtener una propiedad del estilo actual de un elemento
  • Cambiar una propiedad del estilo de un elemento
  • Cambiar varias propiedades a la vez
• Animaciones CSS sencillas
  • Soporta varios atributos a la vez
  • Varios parametros, entre ellos la duración e incluso los frames por segundo
  • Es posible seleccionar la función linear y la cúbica
• Soporte de eventos
  • bind
  • unbind
• Llamadas AJAX
  • Con POST
  • Con GET
  • Con soporte XML
  • Con soporte JSON
  • Con soporte texto plano
• Superligero
  • 3.3 KB minified
  • 1.5 KB gzipped!

Sois libres de usar este framework para lo que os venga en gana, pero no me responsabilizo de nada.

A continuación teneis la versión sin comprimir, y la versión reducida con Google Closure Compiler:

• mansofk-1.0.min.js (3.3 KB para usar en producción, si usas gzip ocupa sólo 1.5KB)
• mansofk-1.0.js (11KB para usar durante el desarrollo)

Ale, pues ya está. Lo suyo sería hacer una demo, pero como ahora mismo tengo otras cosas que hacer, me lo dejo para otra ocasión.

framework, javascript, jquery, js framework, lightweight, mansofk, mooTools

No es nuevo, siempre que actualizo a la siguiente versión de Ubuntu (en este caso la 10.4), me toca pasarme un par de días reconfigurando cosas o reinstalando paquetes.

En fin, que estoy ahora mismo desarrollando una aplicación con Google App Engine (GAE para los amigos), y para no tener problemas al hacer un deployment, lo suyo es tener instalado Python 2.5.

Como no, la gente de Canonical ha eliminado el paquete python2.5 de Ubuntu Lucid, así que ya la tenemos montada. No puedo lanzar el servidor local de Google App Engine.

Por suerte, después de estar indagando e indagando en launchpad.net he encontrado a alguien que se lo ha currado y ha creado los paquetes python2.4 y python2.5 para Ubuntu Lucid Lynx.

Lo único que tienes que hacer es añadir las siguientes lineas en /etc/apt/sources.list

deb http://ppa.launchpad.net/fkrull/deadsnakes/ubuntu lucid main
deb-src http://ppa.launchpad.net/fkrull/deadsnakes/ubuntu lucid main

Y finalmente ejecutar:

$ sudo apt-get update
$ sudo apt-get install python2.5

Y ya está, ya puedes ejecutar GoogleAppEngine en Ubuntu Lucid Lynx.

Enlaces de interés:

• Old Python versions en Launchpad (esta es la web donde dice como añadir los paquetes)
• Python 2.5.5 release page
• Google App Engine

gae, google app engine, ubuntu

Ubuntu 10.4 acaba de salir. Básicamente yo vengo usando Ubuntu desde hace cosa de 4-5 años, y de momento estoy bastante contento.

El gran problema de este release de Ubuntu, a mi parecer, es que han cambiado los botones de control de ventana, y los han puesto a la izquierda, en vez de seguir manteniendolos a la derecha, que es lo que el 95% de los usuarios están acostumbrados.

En fin, que como no me gustaba, he indagado un poco, y la solución ha sido fácil e instantanea:

Hay que pulsar Alt+F2, ponemos el comando gconf-editor y le damos a Enter.

Una vez en el editor de configuraciones, en el desplegable de la izquierda buscamos la ruta app -> metacity -> general y  hacemos doble click en el campo que pone button_layout.

Símplemente hay que cambiar el campo de valor y poner lo siguiente:

menu:minimize,maximize,close

Se le da a cerrar/guardar, y ale, automaticamente las ventanas se reconfiguran.

Ya volvemos a tener los iconos a la derecha.

ubuntu

Pues sí. No voy a explicar los detalles, pero el caso es que por una razón u otra, estaba moviendo las fotos de una tarjeta SD al ordenador, cuando PAAAAM, reseteo del ordenador, con la consiguiente pérdida de las fotos.

Las fotos no estaban ni en el disco duro, ni en la propia tarjeta.  Putada

Cual fue mi asombro, cuando me propuse recuperar mis fotos, y en vez de las 69 fotos que yo quería recuperar, ¡¡recuperé 17 mil!!

Vale, para mi estaba claro que iba a recuperar del orden de 500 a 1000 fotos, pero 17 mil! La virgen santa! Mi vida entera en la tarjeta de memoria.

Para el que se encuentre en mi situación, a continuación os doy una pequeña ayuda.

Pasos para recuperar los datos de una tarjeta de memoria, tarjeta USB o disco duro.

El tema es que hay gente en el mundo que se lo ha currado bastante, y ha hecho herramientas superútiles y supersencillas para recuperar las fotos.

Me consta que existen programas para Windows, pero como yo uso Linux, pues voy a explicar lo que yo hice.

El primer paso, aunque es de sentido común, es no hacer ninguna operación con la tarjeta o el USB en cuestión. Nada de guardar nuevos archivos, porque podrías estar sobreescribiendo los que quieres recuperar. De hecho, lo mejor que puedes hacer, si tienes espacio suficiente en otro disco, es un volcado de memoria. Es decir, guardar TODA la memoria de la tarjeta, tal cual, en un archivo de tu disco duro. Hay programas especializados.

En mi caso, me descargué los paquetes  gddrescue y foremost de Debian/Ubuntu.

Lo primero, para generar la imagen, es ejecutar ddrescue sobre el dispositivo afectado, guardando el archivo en OTRO dispositivo (de no ser así, lo estaríamos sobreescribiendo y perderíamos los datos).

sudo ddrescue -r 3 /dev/<device> /home/<user>/image.dd /home/<user>/image.dd.log

El segundo paso, una vez tenemos la imagen del disco, es usar algún programa para recuperar los archivos. En este punto hay muchas alternativas (ver enlaces de abajo para más detalles). Dado que yo quería recuperar únicamente archivos JPEG de la tarjeta, decidí usar el programa foremost.

foremost -v -q -t jpeg -i /home/<user>/image.dd -o /home/<user>/foremost/

El comando anterior busca archivos en JPG en el archivo image.dd y las imágenes encontradas se almacenan en la carpeta /home/<user>/foremost/

Tras 15-20 minutos, recuperé nada menos que 17579 archivos en JPG.  Por suerte para mi, los primeros 69 eran las fotos que yo quería

Links interesantes:

• Data Recovery using Ubuntu

Nota para los despistados y los precavidos:

Estos pasos no sólo sirven cuando te ha petado la tarjeta de memoria o el USB, también demuestran lo fácil que puede ser recuperar información de una tarjeta de memoria/USB/disco duro donde alguien se cree que borrando un archivo ya no vas a encontrar nada. Los datos siguen ahí hasta que los sobreescribas (o los borres con algún programa especializado).

backup, ddrescue, foremost, recuperar datos

Para quien le sirva, me he pasado un rato haciendo una función en python que fuera equivalente a http_build_query de PHP.

##
# Mimics the behaviour of http_build_query PHP function
# This method can be useful for sending data to flash applications
##################################################
def http_build_query(params, topkey = ''):
  from urllib import quote

  if len(params) == 0:
    return ""

  result = ""

  # is a dictionary?
  if type (params) is dict:
    for key in params.keys():
      newkey = quote (key)
      if topkey != '':
        newkey = topkey + quote('[' + key + ']')

      if type(params[key]) is dict:
        result += http_build_query (params[key], newkey)

      elif type(params[key]) is list:
        i = 0
        for val in params[key]:
          result += newkey + quote('[' + str(i) + ']') + "=" + quote(str(val)) + "&"
          i = i + 1

      # boolean should have special treatment as well
      elif type(params[key]) is bool:
        result += newkey + "=" + quote (str(int(params[key]))) + "&"

      # assume string (integers and floats work well)
      else:
        result += newkey + "=" + quote (str(params[key])) + "&"

  # remove the last '&'
  if (result) and (topkey == '') and (result[-1] == '&'):
    result = result[:-1]

  return result

http_build_query, PHP, Python