django

El primer episodio probando una nueva fórmula con In Silico. Un formato más corto y enfocado en menos temas.

En esta oportunidad hablo con Beatriz, mi hija de siete años, sobre desarrollo web, Python y Django.

Como siempre, bienvenidos todos los comentarios y sugerencias.

La versiones solo audio y vídeo para iPod a continuación.

Llega un momento en que todo desarrollador Django debe pensar en cómo implementará sus proyectos en un servidor de producción. La primera vez que lo hice creí que la mejor opción era utilizar Lighty, Apache, mod_proxy y mod_python; poco después descubrí que estaba equivocado. Usar Apache como servidor web al frente para gestionar todas las peticiones a un proyecto Django y pasar, vía mod_proxy, pedidos de contenido estático a Lighty es una mala idea, con esta configuración Apache trabaja incluso para archivos que no tiene que servir, usando más memoria y CPU que Lighty.

Luego de leer algunos comentarios en el artículo original y más sobre la implementación de Django pude confirmar que lo mejor era tener al servidor web de contenido estático al frente y Apache detrás, procesando las páginas generadas por Django.

Reemplacé Lighty con Nginx, que de acuerdo a muchos parece ser más estable, y opté por mod_wsgi en vez de mod_python para conectar Apache con Django. mod_wsgi usa además menos memoria y está preparado para sitios con mayores exigencias. No hay necesidad de mod_proxy en Apache pues Nginx se encarga ahora del trabajo de proxy.

La siguiente es una breve guía, muy precisa y fácil de seguir, para desarrolladores web que saben cómo administrar sus servidores. No tocaré temas como seguridad, memcached, configuración de Django, bases de datos, Apache, DNS u otros aspectos básicos de GNU/Linux. Por supuesto que todos estos temas son también importantes y debes saber cómo encargarte de ellos.

El plan

Esta guía te permitirá configurar un servidor para Django en Ubuntu e incluye todos los pasos para:

• Configurar un dominio para tu proyecto en Django.
• Crear una estructura de directorios para tus sitios en Django.
• Configurar Apache con mod_wsgi para Django.
• Configurar Nginx.
• Servir archivos estáticos para la sección de administración de Django.
• Mostrarle tu próximo éxito en Django al mundo.

Luego de seguir estos pasos tendrás un sitio corriendo con Nginx al frente y Apache hablando con Django detrás. Nginx se encargará del contenido estático y pasará las peticiones de Django para Apache y mod_wsgi.

He probado los pasos a continuación en tres servidores Ubuntu (dos corriendo 8.10, Intrepid Ibex, y otro con 7.10, Gutsy Gibbon) pero todo debería funcionar muy parecido en otras distribuciones de GNU/Linux.

¿Empezamos?

Manolo Guerrero, ese mexicano tan divertido que resulta ser un dios de jQuery y excelente amigo me presentó a Andreas Krohn, un emprendedor y desarrollador sueco que es la mente maligna detrás de WebHostNinja. Con Andreas he desarrollado una muy simpática aplicación para Facebook que corre sobre Google App Engine y Django. La aplicación será oficialmente lanzada en unos días y escribiré más sobre ella pronto.

Andreas ahora está considerando usar Django para su próximo proyecto y me hizo algunas preguntas, preguntas que estoy seguro muchos otros desarrolladores deben haber tenido así que decidí publicar mis respuestas y ayudar a quienes recien empiezan.

Y justo cuando pensaba que configurar Apache, mod_python y Lighty con Django era todo un logro, incluso antes de jugar con mod_wsgi o nginx (el poderoso servidor HTTP ruso que suena como engine X) llegó el pedido de mover la aplicación Django que estoy escribiendo para Facebook a Google App Engine, el nuevo, y parece que el más popular por estos días, protagonista en el mercado de las nubes.

Cuando mi código corría en un ambiente de Django puro apunté el callback url en Facebook a mi servidor local, un sencillo cambio en el port forwarding de mi router bastó, y ahora quería hacer lo mismo con el servidor de desarrollo de Google App Engine.

Comprender y usar expresiones regulares (regular expressions o simplemente regex en inglés) es vital para todo programador en todo lenguaje. Django las usa en su muy elegante sistema para manejar los url.

He trabajado con expresiones regulares durante mucho tiempo y leído una buena cantidad de libros sobre el tema pero si tendría que recomendar uno me quedo con el clásico Mastering Regular Expressions
de Jeffrey Friedl.

Y nada mejor para probar que estás sobre la pista correcta al escribir tus propias expresiones regulares que Kodos, una sencilla pero muy útil aplicación escrita en Python. Además es muy fácil de instalar con un sencillo sudo apt-get install kodos desde distribuciones basadas en Debian, como Ubuntu.

Hace poco comenté sobre el importante detalle de usar las comillas correctas en Python y simplejson y hoy me encuentro con otro caso similar en Django.

El detalle se encuentra en las plantillas de Django, me estoy refiriendo a la versión 1.0, al usar la etiqueta {% url %}, muy útil para nombres en los patrones de los URL.

Imaginemos un url como el siguiente en tu URLConf:

url(r'^add/chatroom/(?P\w+)$', 'myapp_chatroom_add', name='myapp_chatroom_add'),

Ahora es posible insertar {% url %} en una plantilla para obtener el url correcto de esta manera:

{% url myapp_chatroom_add chatroom_data="abc" %}

Nota que estoy pasando el texto "abc" entre comillas dobles al parámetro chatroom_data de la función.

Y aquí viene lo importante, las siguientes dos formas no funcionarán:

{% url myapp_chatroom_add chatroom_data=abc %}

pues no usa comillas. Ni esta:

{% url myapp_chatroom_add chatroom_data='abc' %}

que utiliza comillas simples.

Los errores pueden variar dependiendo del contexto pero lo importante es notar que al pasar parámetros que no sean números a {% url %} es necesario usar comillas dobles.

Si estás usando números puedes usar comillas dobles o remover por completo las comillas pero las comillas simples tampoco funcionarán.

Actualización, 8 de abril de 2009: Ya no recomiendo este método. Ahora sugiero seguir la guía para configurar un servidor Django con Nginx y Apache.

Es octubre 2008 y ya no queda duda que para hacer desarrollo web en serio se debe trabajar con frameworks. Talvez la traducción adecuada sería plataforma pero como la mayoría de desarrolladores de habla hispana estamos acostumbrados me quedaré con la palabrita en inglés. Un framework es software que permite a los programadores, que cada día somos más ociosos, olvidarnos de las tareas repetitivas para enfocarmos en aquello que hace único a cada uno de nuestros proyectos.

Además resulta obvio que Django, el framework escrito en Python, está atrayendo a más desarrolladores y compañías cada día. Guido es un googler desde el año 2005 y el recientemente anunciado Google App Engine usa Python y Django. Estoy seguro que no hay mejor momento para saltar al tren de Django (sin ánimos de embromar a los buenos chicos de RoR).

Los programadores veteranos pueden empezar a escribir aplicaciones Django rápidamente gracias a la excelente documentación y al libro de Django (de acceso gratuito). También he leido y recomiendo Practical Django Projects, por James Bennett, parte del equipo de Django, y Learning Website Development with Django, por Ayman Hourieh, un joven y talentoso ingeniero en Google.

Django es realmente el web framework for perfectionists with deadlines. Yo estoy a punto de completar mi primera aplicación Django para Facebook y solo necesité unos pocos días para lograrlo (lo cual incluyó actualizarme con los recientes cambios en el API de Facebook). Y sí, hay artículos sobre Django y Facebook en camino.

Y bien, ¿así que todo es felicidad en Djangolandia? Bueno, hay algo que siempre me complicó desde que empecé a usar el framework hace algunos meses: la puesta en marcha en un entorno de producción. La documentación y los libros que he leido suelen arrancar con el servidor de desarrollo que Django incluye y enfocarse en escribir aplicaciones, dejando la implementación final de lado.

Pero desafortunadamente, especialmente si estás acostumbrado a la típica configuración de Linux, Apache, MySQL y PHP, como yo lo estaba, puedes necesitar más detalles para entrar en acción. Es por eso que decidí escribir este tutorial sobre cómo configurar Apache, mod_python y un proxy reverso a Lighttpd para Django.

Continuando el desarrollo de mi aplicación Django para Facebook compartiré algunas ideas sobre cómo configurar Apache y mod_python.

La mayoría de pasos están muy bien descritos en la documentación de Django, pero pueden ser necesarios algunos detalles más. Veamos.

Recientemente he estado escribiendo una sencilla aplicación Django para Facebook.

Empecé con algo sencillo usando HTML en local, usando el servidor de desarrollo que Django ofrece, y luego hice algunos cambios en las plantillas para utilizar FBML de acuerdo a una variable que llamé IN_FACEBOOK y que inserté en settings.py.

Luego añadí PyFacebook para conectarme al API de Facebook desde Python y configuré mi aplicación de acuerdo a las instrucciones de Facebook.

Finalmente modifiqué la configuración de port forwarding en mi router para que Facebook pueda conectarse a mi servidor en casa usando el IP público, y dinámico, de mi conexión.

Todo iba bien hasta que empecé a notar que luego de cada cambio en mi código la aplicación en Facebook retornaba un código HTTP 200.

Creí que se trataba de un problema en mi conexión ADSL y decidí mover la aplicación a un servidor real, con un IP público fijo, pero el problema continuaba. Luego de cualquier cambio en mi código Facebook retornaba HTTP 200 en la aplicación. Para corregir el problema necesitaba refrescar el navegador tres o más veces.

Y aún cuando mi aplicación se encuentra en desarrollo empecé a sospechar del servidor que Django ofrece y opté por configurar Django con Apache y mod_python.

!Presto¡ Ese era el origen del problema. Por lo visto el tiempo de respuesta del servidor de desarrollo de Django era muy corto para Facebook.