jump to navigation

Cómo se hizo el mapa de calor March 30, 2009

Posted by Bosco in : django/python, dooplan , add a comment

En el anterior post explicaba lo que era el mapa de calor de dooplan. Robert construyó la solución (a partir de otro desarrollo) y aquí explica cómo funciona.

pdb.set_trace() en Google App Engine January 25, 2009

Posted by Bosco in : django/python, programación , add a comment

GAE redirecciona todo el stdout a la salida del navegador (response), por lo que el pdb tal cual no funciona. Para hacerlo funcionar hay que hacer un pequeño truco:

import sys, pdb
for attr in ('stdin', 'stdout', 'stderr'):
    setattr(sys, attr, getattr(sys, '__%s__' % attr))
pdb.set_trace()

Yo lo he encapsulado en un fichero, así puedo usarlo más o menos como antes. Lo he llamado gpdb.py:

import sys
import pdb

def set_trace():
    for attr in ('stdin', 'stdout', 'stderr'):
        setattr(sys, attr, getattr(sys, '__%s__' % attr))

    return pdb.set_trace()

Y para usarlo, en mi código añado:

            import gpdb; gpdb.set_trace()

Y el Amigo Invisible llegó a la nube January 25, 2009

Posted by Bosco in : amigoinvisible, django/python, programación, web2.0 , 1 comment so far

He subido el amigo invisible versión Django + GAE y ha funcionado! Aquí tenéis una versión primitiva de la aplicación, pero que funciona al 100%. Y con múltiples exclusiones!

TODOs:

PD. Tengo un límite de 2000 emails por día. Esto puede ser un problema, estas navidades estuve enviando más de 4000 al día, tendré que preguntar precios.

Primeros pasos con GAE y Django January 25, 2009

Posted by Bosco in : django/python, programación , add a comment

Mi tutorial step-by-step:

application: aio
version: 1
runtime: python
api_version: 1
handlers:
- url: /static
static_dir: site_media
- url: /.*
  script: main.py
import logging, os, sys

# Google App Engine imports.
from google.appengine.ext.webapp import util

# Remove the standard version of Django.
for k in [k for k in sys.modules if k.startswith('django')]:
  del sys.modules[k]

# Force sys.path to have our own directory first, in case we want to import
# from it.
sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))

# Django imports and other code go here...
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
import django.core.handlers.wsgi

def main():
  # Run Django via WSGI.
  application = django.core.handlers.wsgi.WSGIHandler()
  util.run_wsgi_app(application)

if __name__ == '__main__':
  main()

Tengo el amigo invisible más o menos listo, tengo que probar el envío de mails, y luego lo subiré a los servidores de Google. A ver si mañana lo termino.

Google App Engine January 24, 2009

Posted by Bosco in : amigoinvisible, django/python, programación , add a comment

Llevo esta tarde peleándome con el Google App Engine, para portar el amigo invisible a esto. Y no ha sido trivial. Por un lado, te quedas sin admin. La consola de administración del GAE no es para nada lo mismo. Por otro lado, y mucho mucho mucho más importante, no puedes usar import pdb;pdb.set_trace() Cómo puedes debugar sin eso?!!

Las diferencias con django se producen en la parte de BBDD, ya que se sustituyen los models de django por el sistema de Google. La definición es sencilla, pero los métodos para hacer queries dejan mucho que desear. Y las exceptions lanzadas también son diferentes.

Ojo también con los forms. Los ModelForms se extienden de un paquete de GAE, mientras que los forms normales son los de Django.

Por último, es posible y fácil utilizar Django en su versión actual. Simplemente hay que definir un archivo main.py (y declararlo en el app.yaml), con el siguiente contenido:

import logging, os, sys

# Google App Engine imports.
from google.appengine.ext.webapp import util

# Remove the standard version of Django.
for k in [k for k in sys.modules if k.startswith('django')]:
  del sys.modules[k]

# Force sys.path to have our own directory first, in case we want to import
# from it.
sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))

# Django imports and other code go here...
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
import django.core.handlers.wsgi

def main():
  # Run Django via WSGI.
  application = django.core.handlers.wsgi.WSGIHandler()
  util.run_wsgi_app(application)

if __name__ == '__main__':
  main()

Trucos de Django Admin December 31, 2008

Posted by Bosco in : django/python , add a comment

Django Admin me sigue pareciendo una herramienta clave dentro de django. Es terriblemente potente y flexible. Es verdad, como dice nuestro compañero de trespams, el admin no es para el usuario final, pero puede ser un herramienta super útil para el usuario interno. En dooplan usamos el admin (entre otras cosas) para el equipo de editores de los eventos.

Con el Admin cada editor tiene los permisos de acceso a lo que le corresponde, tienen filtros y búsquedas a su medida, formularios muy fáciles de rellenar (hasta campos autotext!), histórico de modificaciones… Es una plataforma que con muy poco esfuerzo nos ha ofrecido una solución potentísima, que un desarrollo a medida no lo habría hecho mejor (y a que coste…)

Pues bien, el otro día James Bennett proponía un par de trucos interesantes para hackear aún más el admin. Yo completo ese tutorial con otro truco interesante. Cómo mostrar un formulario para el alta y otro para la modificación de un mismo modelo. Este caso puede ser interesante para simplificar el alta de un objeto, pero mantener el control completo en caso de la modificación.

Simplemente hay que sobreescribir los métodos add_view() y change_view() del ModelAdmin. Siguiendo con el ejemplo propuesto por Bennett, si queremos que en el alta solo tuviéramos que entrar title, slug y body, y en la modificación quisieramos ocultar el slug (para evitar que se modifique la url) y la fecha podríamos hacer esto:

class EntryAdmin(admin.ModelAdmin):
    ...
    def add_view(self, *args, **kwargs):
        self.fields = ('title','slug','body')
        return super(EntryAdmin, self).add_view(*args, **kwargs)

    def change_view(self, *args, **kwargs):
        self.fields = ('title','body','subject','author')
        return super(EntryAdmin, self).change_view(*args, **kwargs)

Por supuesto, podemos ser aún más vagos y sobreescribir solo uno de los métodos, y dejar que el otro coja los parámetros por defecto:

class EntryAdmin(admin.ModelAdmin):
    ...
    fields = ('title','body','subject','author')

    def add_view(self, *args, **kwargs):
        self.fields = ('title','slug','body')
        return super(EntryAdmin, self).add_view(*args, **kwargs)

Esto también funcionaría

Mi primer snippet (chispas) December 30, 2008

Posted by Bosco in : django/python , add a comment

Hoy me ha salido casi sin querer mi primer djangosnippet. Es un filtro para el admin, para poder seleccionar ver solo los elementos con el campo a null, o los que tengan valor, o todos juntos.

Funciona cuando quieres filtrar un campo genérico (un numérico, un string…) y este campo es nullable. Si no tuvieras este filtro te aparecen todos los valores posibles (completamente inutil en este tipo de campo). Si el campo no es nullable, este filtro no se activa.

El filtro hay que aplicarlo como parche sobre un fichero de django.

migrations October 10, 2008

Posted by Bosco in : django/python, programación , add a comment

A una semana (más o menos) de nuestra salida en beta hemos empezado a utilizar migraciones. Hasta ahora no eran necesarias, ya que en periodo de desarrollo construyes y te cargas la bbdd tantas veces como necesites, pero ahora que ya tenemos a nuestros editores empezando a introducir información en la BBDD no podemos permitirnos ese lujo.

Así que hemos empezado con las migraciones. Para quién no sepa lo que son las migrations es una técnica que permite hacer modificaciones sobre la BBDD (el esquema) de una forma controlada. Es decir, cuando el desarrollador necesita crear una nueva columna, por ejemplo, lo hace a través de una migración, es decir un comando que se ejecutará para hacer los cambios automáticamente y de forma controlada.

En Ruby On Rails está muy bien resuelto, y viene por defecto con el framework. La verdad que es una de las características que más envidio de RoR. Django sin embargo no viene con ellas por defecto, pero existen 3 plugables:

  • Django-evolution, el más veterano, pero un poco limitado. Solo controla una serie de cambios, un poco limitados en mi opinión
  • South, una interesante y atractiva opción. Sin embargo, las pruebas que he hecho no han sido satisfactorias
  • DMigrations, proyecto liderado por Simon Wilson , un django-evangelist británico, que es el que más me ha gustado y estamos utilizando. Exige que sea el desarrollador quién informe al sistema de las migraciones, mientras que en los otros el sistema es quien las descubre, pero permite mayor flexibilidad.

Festuc en Django October 8, 2008

Posted by Bosco in : django/python, dooplan , 4comments

Hoy los amigos de Festuc están actualizando su web con una nueva versión hecha en Django. Enhorabuena festuceros! Nos habéis ganado en la carrera de ser la primera (gran) web hecha en Django en Cataluña. A nosotros nos falta nada, un par de semanas.

Festuc y dooplan tienen mucho en común, además de que ambas plataformas serán Django, compartiremos un mismo objetivo, convertirnos en referencia del ocio. Sin embargo el enfoque es ligeramente diferente. Mientras ellos van a por un target de twenty something, fiesteros, aves nocturnas…, nosotros desde dooplan intentaremos posicionarnos en un rango de edad superior y con una oferta de ocio más variada. No queremos centrarnos en fiestas exclusivamente, queremos también llegar a esos que disfrutan con una buena exposición, una conferencia, una feria, con sus hijos, con su pareja… Un público diferente.

consensus, otro motor de filtrado colaborativo en python September 30, 2008

Posted by Bosco in : django/python, programación, recommenders , add a comment

Jordi me ha pasado un link a Consensus, una sencilla librería python para filtrado colaborativo. Es extremadamente sencilla (que no simple) por lo que se puede entender facilmente la filosofía detras. Interesante.