He tenido el placer de poder asistir a la DjangoCon Europe que tuvo lugar en Amsterdam. En contra de lo que se puede suponer a priori, el viaje a Amsterdam fue de todo menos un viaje de ocio. Con decir que tuve que quedar con un español que vive allí, el futuro compañero de Yaco Danny Navarro, para visitar Amsterdam (bueno sólo ir a ver algunos escaparates, sin comprar nada por supuesto que hay crisis ;)

En fin, que me lo pasé en grande con casi 200 geeks que asistían a la conferencia (cinco de ellos españoles :). Bueno, en realidad sólo me lo empecé a pasar bien a partir del lunes por la tarde, una vez había dado mi charlita de 10 minutos sobre Merengue (transparencias en HTML5 aquí), dentro de charla 3 CMSs in 45 minutes. Hasta entonces sólo había sido un cúmulo de nervios y de trabajo de preparación, debido a mi mal inglés. Menos mal que al parecer salió bien la cosa y a muchos le gustó Merengue.

Con respecto a la primea DjangoCon de 2008, a la que asistí con Marc García, ha habido muchas diferencias. El sitio no era GooglePlex, cierto es, pero también es cierto que... We conquered the Castle! En serio, la gran mayor diferencia que veo es que se nota estos tres años de alto crecimiento de Django y sobre todo tres años de recorrido de muchas empresas, organizaciones e individuos que han ido creciendo alrededor, y todos encantados de su experiencia.

No sabía que sitios como Prezi era Django, así como todas las webs que se están haciendo en Mozilla, como la de addons (código liberado en github), como la famosa que recogía las descargas en tiempo real del FF4. Por ejemplo la de addons recibe más 500 millones de peticiones a su API para la comprobación de nuevos addons y temas similares. También los chicos de bitbucket,org lo hacen todo con Django. Muchas webs e iniciativas exitosas son en Django: djangozoom, ep.io, disqus, etc. etc. En 2008 sólo teníamos un par de referencias como Pownce. Por cierto, allí de nuevo estaba la guapa Djanguera Leah Culver, co-desarrolladora de Pownce (ahora no existe).

Estos tres años han dado además para encontrar un sin fin de código liberado para Django que era el topic de las charlas o se usaban en los proyectos mencionados anteriores. Estos proyectos ni se intuían hace tres años y algunos tampoco los conocíamos antes de las conferencias (estaban en un github perdido). Cito algunos ejemplos:

• Celery, para tareas asíncronas (usado en Yaco con éxito).
• Fiber, un set de funcionalidades de CMS para añadir a tu proyecto Django, presentado por Dennis, una gran persona.
• Django-qunit, para integración de django y qunit, que permiten hacer tests en Javascript. Se pueden ejecutar en varias máquinas usando jstestnet.
• django-cache-machine, basado en el antiguo django-caching, que es una alternativa menos mágica a Johnny-cache.
• django-waffle, para hacer test AB según ciertos flags activos o no.
• django-bleach, para evitar ataques de inyección de Javascript.
• django-queryset-transform, que permite evitar consultas SQL tomando el control del ORM, para cuando el select_related es insuficiente.
• django-nani, para traducción de modelos usando la aproximación en dos tablas, como hacía django-multilingual pero mucho mejor que este último. En merengue se usa django-transmeta, que se basa en una tabla con columnas para cada idioma.
• django-qmixin que permite una personalización elegante de tus managers y querysets.
• django-rest-framework, que parece mejor pensado que django-piston. Es curioso como a la gente no le termina de convencer django-piston y están tomando otros productos, aunque dicen los de bitbucket que van a sacar una mejor versión pronto. El producto que al parecer está más de moda es django-tastypie, que tiene sin duda la mejor documentación de todos.
• kong para testing funcional cuando Selenium se convierte en un cañon para matar moscas (depende de la naturaleza de la web que programes).
• dagny, o como aprovechar el REST para mejorar la estructura y reutilización de tu código. Esta es otra gran alternativa a django-piston pero además te cambia el modelo de como programar. Un modelo elegantísimo.
• etc.

Por otra parte, como ya le pareció a Loren en la PyCon, veo que estamos haciendo las cosas bien, tanto en desarrollo como en despliegue. Para integración continua usan Jenkins, como estamos empezando a usar nosotros. Otros usan bamboo. Para creación de máquinas y mantenimiento usan puppet y chef. Muchos usan la nube para ello.

Aunque todas estuvieron interesantes, voy a destacar algunas charlas especialmente:

• La lightning talk de PyCharm. Es sin duda el mejor IDE Django que hay. Permite autocompletado de todo, incluyendo dentro de las plantillas Django (carga de librerías, expresiones, filtros, ¡todo!). Lo único malo es que tarda mucho en cargar por el análisis que hace al proyecto que carga. Como curiosidad el desarrollador principal es un geek superdotado que entró a la universidad con 15 años (y se arrepiente mucho de ello).
• Muy interesante la charla de compass y less y del responsive web design.
• La charla de django on rails que trata de como aprender del modelo restful de Rails y aplicarlo a Django. El resultado es dagny, mencionado antes.
• La charla de reusable apps using "eicht spaces", me parecío como analizaba el problema del import circular en Django y permitía un diseño de vistas que dejaba mucha mayor reutilización. Permite por ejemplo que puedas extender el modelo de una aplicación en una segunda aplicación que sea el modelo que usa la primera aplicación, pero sin el problema del import circular que es el que saldría si intentaras hacerlo sin un artefacto ingenioso como "eicht spaces".

Otra cosa interesante fue ver a Reinout van Rees escribiendo los artículos de blog de las charlas que iba viendo en tiempo real como si de una taquígrafa se tratara. ¡Very cool!

Por último los Sprints. Fueron en el castillo de De Waag, y la verdad es que pasamos un rato agradable. Yo estuve con Samuel Fuentes, el único de los españoles que se quedó a los sprints. La verdad es que sólo trabajé sprintando en Django unas 5-6 horas, en las cuales metí mano a 3-4 tickets del trac de Django. El resto estuve también ayudando a gente, desarrollando con Merengue, preparando el sprint de la EuroPython, contestando correos, redactando documentación de Yaco, etc.

Al final llegó Danny Navarro y pasamos un buen rato de charla juntos hasta las 1 y pico de la mañana.

En fin, unas conferencias magníficas, la gente estupenda, una organización increíble, pendiente de los asistentes en cada momento, con buena comida (el queso genial), mejor cerveza belga. Eso sí, hay algo que fallo en la DjangoCon Europe... faltó Cal Henderson

Today I needed to create an app file for MacOS X with a simple Python script. This is what I learned:

• Use py2app, it's your friend
• After installing py2app with easy_install you need to fix it. Otherwise it may not work for your hardware architecture. See Section 2 of this blog post
• Now, you can safely run python setup.py py2app and you will get a file with the .app extension in the dist directory
• When you install that (copy into your Applications folder) and try to run it you will get this error (open the Console or do a tail -f /var/log/system.log) to see the error:

22/03/11 10:33:21    com.apple.launchd.peruser.502[580]    ([0x0-0x98098].org.pythonmac.unspecified.myscript1613]) Exited with exit code: 255
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]    Traceback (most recent call last):
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]      File "/Applications/xml2rfc.app/Contents/Resources/__boot__.py", line 103, in <module>
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]        _argv_emulation()
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]      File "/Applications/xml2rfc.app/Contents/Resources/__boot__.py", line 101, in _argv_emulation
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]        _get_argvemulator().mainloop()
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]      File "/Applications/xml2rfc.app/Contents/Resources/__boot__.py", line 40, in mainloop
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]        stoptime = Evt.TickCount() + timeout
22/03/11 10:34:53    [0x0-0x9b09b].org.pythonmac.unspecified.myscript[1645]    AttributeError: 'module' object has no attribute 'TickCount'

In order to avoid it you need to use a different Python from your system Python. In my case it only worked with a 32 bits Python like python-2.7.1-macosx10.3.dmg

Once you have the script installed you can run it from the shell in /Applications/myscript/MacOS/myscript.py

For the record, this is my setup.py file:

import sys
from setuptools import setup

mainscript = 'myscript.py'

if sys.platform == 'darwin':
    extra_options = dict(
        setup_requires=['py2app'],
        app=[mainscript],
        # Cross-platform applications generally expect sys.argv to
        # be used for opening files.
        options=dict(py2app=dict(argv_emulation=True)),
        )
elif sys.platform == 'win32':
    extra_options = dict(
        setup_requires=['py2exe'],
        app=[mainscript],
        )
else:
    extra_options = dict(
        # Normally unix-like platforms will use "setup.py install"
        # and install the main script as such
        scripts=[mainscript],
        )

setup(
    name='myscript',
    version='0.1.0',
    **extra_options
)

It's taken from a py2app example

La versión 0.8 de Merengue va a centrarse en mayor medida en tener un CMS production ready para grandes portales web, con una carga dinámica importante y un número de peticiones elevados.

Una de las acciones a tomar será compatibilizarlo con la versión 1.3 de Django, ya que, sobre todo a partir de la versión 1.2, se han realizado muchas mejoras en rendimiento, escalabilidad, robustez y seguridad. Así, compatibilizarlo con Django 1.3 (hasta ahora usaba Django 1.1) es una de las mejores formas de preparar Merengue para grandes webs.

Las mejoras que dispondríamos relativas a estas cuestiones serían:

• ORM multidatabase. Con poco esfuerzo puedes tener varias bases de datos configuradas en cluster.
• Caché de plantillas. La página inicial de Merengue, cuando entramos como un usuario autenticado, nada más instalar Merengue, renderiza ni más ni menos que 87 plantillas, pero tenemos casos de proyectos con vistas que renderizan hasta 206 plantillas. Estos números no son habituales en aplicaciones web ad-hoc, pero Merengue es un CMS pluggable de propósito general. El número es tan elevado porque:
  • Merengue renderiza las páginas a partir de elementos pequeños (bloques, acciones, viewlets, etc.) que pueden ser movidos configurados y desactivados por el gestor. Esta flexibilidad casi infinita tiene el inconveniente de renderizar los fragmentos de la página de forma separada, lo cual también es bueno para permitir que los desarrolladores integren sus plugins.
  • Merengue usa bastante la herencia de plantillas, por ejemplo para su sistema de temas (theming) y para los bloques. Por ejemplo cada bloque suele heredar de una plantilla padre que incluye herramientas para gestionarlos, moverlos, configurarlos, etc.
• Protección contra ataques CSRF, para evitar que otras webs hackeadas puedan alterar datos de la nuestra.
• Claves naturales en Fixtures, perfectas para mejorar el deployment. Por ejemplo para exportar automáticamente la configuración de un sitio Merengue (con el tema activo, los bloques, plugins activados, configuración, etc.) e importarlos en otro sitio distinto.
• Uso de Model.objects.only(...), para seleccionar campos sueltos de las tablas, y no tener que cargar toda la tabla completa para cuando listas solo un par de campos en ella. Esto puede ser muy útil por ejemplo para las colecciones, ya que si el gestor define los campos que muestra, ¿para qué tener que obtener todos los demás si nunca van a salir?
• Framework para Logging (1.3), que ya era hora de que se incluyera en este framework. Así evitamos el estar poniendo print y podemos configurarlo para enviar entrada a fichero, email, etc.
• Ficheros estáticos (1.3). En Django 1.3 se distinguen los ficheros subidos por los usuarios de los servidos por el sistema. También hay herramientas de sincronización al directorio que sirve el servidor web usado. Merengue también tiene funcionalidades que equivalen a las de Django (y las superan en algunos casos), con los que habrá que pensar más tranquilamente como unir los caminos.

Pues bien, ya hemos empezado el trabajo de compatibilizarlo con Django 1.3, realizado en una rama aparte de código y las noticias son muy buenas... tan buenas... que puedo decir que tras unas 6 horas de trabajo la tarea está casi concluida. Falta probarlo bien y corregir los problemillas que surjan, pero tras múltiples refactorizaciones, fallitos corregidos, pruebas y pruebas, casi está listo (el trabajo se puede ver en el ticket #1568).

Benchmarkings preliminares

Lo primero que he realizado tras comprobar que funciona bien han sido pruebas de carga simples, comparando Merengue (rama trunk/) + Django 1.1 y Merengue (rama django1.3_compat) + Django 1.3, con y sin caché de plantillas habilitado (usando caché de memoria local).

Aquí los resultados:

• Merengue con Django 1.1:
  
  • Vista con 87 plantillas: 2.85 [#/sec]
  • Vista con 209 plantillas: 1.20 [#/sec]
• Merengue con Django 1.3:
  • Vista con 87 plantillas, sin cache: 2.88 [#/sec]
    
  • Vista con 87 plantillas, CON cache de plantillas: 6.35 [#/sec]
  • Vista con 209 plantillas, sin cache: 1.06 [#/sec]
  • Vista con 209 plantillas, CON cache de plantillas: 6.35 [#/sec]

Conclusiones del benchmark:

• La caché de plantillas aumenta drásticamente el rendimiento de un sitio.
• Cuanto más plantillas renderiza una vista, más se nota el aumento de rendimiento. De hecho en las pruebas se ve que se consiguen los mismos resultados con 87 plantillas y con 206, lo que denota que el tiempo de localizarlas en el sistema de ficheros y compilarlas es mucho más importante que el tiempo de renderizado de las mismas.

Hoy trabajando en Yaco Sistemas he aprendido algo nuevo sobre cron. Seguramente muchos de los que os moveis entre GNU/Linux y similares, conoceréis el demonio cron.

Cron es un planificador de tareas que nos permite ejecutar una tarea en un momento determinado en el tiempo. La sintaxis para configurar una tarea cron es la siguiente:

.---------------- minuto (0 - 59)
|  .------------- hora (0 - 23)
|  |  .---------- día del mes (1 - 31)
|  |  |  .------- mes (1 - 12)
|  |  |  |  .---- día de la semana (0 - 6) (Domingo=0)
|  |  |  |  |
*  *  *  *  *  comando para ser ejecutado

De esta forma, imaginad que queremos apagar nuestro ordenador los sábados a las 21:30h, configuraríamos una tarea cron de la siguiente forma:

30 21 * * 6 /sbin/shutdown -h now

Podemos planificar tareas para un usuario utilizando el comando crontab:
crontab -l Lista las tareas cron para el usuario actual.
crontab -e Permite configurar una tarea cron para el usuario actual. Se abrirá el editor de texto configurado por defecto en el sistema.
crontab -r Elimina las tareas cron configuradas en el usuario actual.
crontab -v Muestra la última vez que se editó crontab del usuario actual.

La verdad es que no parece una sintaxis muy complicada pero a mi, personalmente, siempre se me olvida.

Como os decía al principio, hoy he descubierto los horarios predefinidos en crontab gracias a ant30. Estos horarios predefinidos son unos valores que se pueden usar para sustituir la sintaxis de las expresiones anteriores. Estos valores predefinidos son:

@yearly Se ejecuta una vez al año. Equivalente a 0 0 1 1 *
@annually (igual que @yearly). Equivalente a 0 0 1 1 *
@monthly Se ejecuta una vez al mes. Equivalente a 0 0 1 * *
@weekly Se ejecuta una vez a la semana. Equivalente a 0 0 * * 0
@daily Se ejecuta una vez al día. Equivalente a 0 0 * * *
@midnight (igual que @daily). Equivalente a 0 0 * * *
@hourly Se ejecuta una vez cada hora. Equivalente a 0 * * * *
@reboot Se ejecuta en el arranque y al reiniciar.

El que yo he utilizado hoy ha sido @reboot que me permite ejecutar un comando cuando arranca el sistema. En mi caso quería que cada vez que se arranque el sistema, se iniciara un servicio desplegado con el usuario en cuestión. Gracias a @reboot no tengo que crear un script en /etc/init.d/ y activarlo en el arranque ;-)

Un saludo!

Tras más de 300 tickets cerrados y dos meses de trabajo, se ha publicado la versión 0.6.0-final de Merengue, disponible en Pypi.

Esta versión final supone la corrección de muchos errores, y sin ningun cambio funcional desde la versión 0.6.0-alpha, y pensamos está lista para su uso en webs de producción. Para el que no conozca el proyecto, recomiendo echar un ojo al overview de Merengue y entrar en la web de demostración

Algunos enlaces de interés:

• Página del proyecto
• Web de demostración (usa la versión 0.7.0-alpha)
• Documentación
• Comparativa entre Merengue y otros CMS Django

Gracias a todo el equipo de Merengue, gracias a ellos el proyecto Merengue se ha hecho realidad.

Mi problema en concreto, era que no podía cargar una base de datos postgresql de un sistema con postgis1.3 a un sistema con postgis1.5. Uno de los muchos errores, era que no encontraba la liblwgeom.so.

La solución es usar el script new_postgis_restore.pl. El mismo comando al ejecutarlo sin parámetros, indica los pasos a seguir:

La semana pasada, el día 28 de Octubre tuvo lugar el primer laboratorio andaluz de android.