Desarrollando con Dojo, Django 1.0, Dojango y Google App Engine

Después de un lapso de varios mesos de haber desarrollado mi primer prototipo de aplicación, volví a retomar el desarrollo en Google App Engine por un proyecto interno nuevo que surgió en mi empresa Eforcers. Esta vez la aplicación a desarrollar es una herramienta que está planteada a largo plazo y que va a ir evolucionando según nuestras propias necesidades. Por este motivo al mirar atrás, vi que utilizar el framework web_app de Google no era la solución más robusta e indicada para el alcance del proyecto, en especial teniendo a Django como una posible alternativa. A continuación voy a presentar los recursos que utilicé para luego plantear el problema y ver como las fichas del rompecabezas van cuadrando y mostrar mi solución.

Los Recursos

En esta travesía el primer recurso que fue fundamental, fue una de las sesiones de Google I/O a que no pude asistir por conflicto de horarios, pero afortunadamente fue grabado en video y subido a YouTube. En esta sesión Guido van Rosum, creador de Python y empleado de Google, explica muy claramente y con ejemplos cómo aprovechar lo mejor de Django en el App Engine e introduce el segundo recurso; el proyecto Google App Engine Django desarrollado por dos empleados de Google.



Este proyecto sirve como "ayudante" y provee la implementación de los archivos básicos para cualquier aplicación que quiera usar Django en App Engine teniendo en cuenta las restricciones impuestas. El proyecto se compone de los archivos: main.py, manage.py, settings.py, urls.py, el famoso app.yaml y el directorio de la librería appengine_django que entre otras provee una implementación de contrib/auth de la cual hablaré en un futuro post. Este artículo introduce el proyecto, muestra su uso y configuración.

Desde el punto de vista de la interfaz de usuario, simplemente ya no me preocupo por la selección de la librería, Dojo Toolkit ofrece todo lo necesario y versión tras versión es mejor. Sin embargo para la integración con Django y minimizar la plomería, valío la pena experimentar con un proyecto de la gente de Uxebu, todos ellos commiters de dojo, el proyecto es dojango y resulta muy útil para evitar código que usualmente se repite página tras página como la definición del perfil de dojo usado (local, cross domain, AOL o Google) la versión, los estilos CSS del tema, entre otras bondades; en el futuro sus creadores prometen integrar con django.forms para la generación automática de los dijits.

El Problema

En resumen el problema de raíz fueron las versiones. En primer lugar Google App Engine incorpora la versión 0.96 de Django, la cual es una versión desactualizada y no incluye muchas de las mejoras que están en la versión 1.0, el motivo 0.96 era la versión más estable al momento de desarrollo del App Engine, además dojango requiere una versión mayor o igual a 1.0. Otra parte del problema fue que el "ayudante" únicamente soporta la versión 0.96 o la última de desarrollo.

Otro problema que surgió, esta vez por restricciones del App Engine en producción fue el límite de 1000 archivos para la inclusión de Django.

La Solución

En definitiva la solución fue muy simple pero a la vez muy inusual, bajar las últimas versiones del trunk de subversión de todos los proyectos, aparte de cierta familiarización con el comando svn checkout este proceso no requiere nada más.

En cuanto a la otra preocupación, aprovechando el reciente soporte a zipimport la solución fue seguir las instrucciones planteadas en este artículo:

1. Descargar Django
2. Empaquetar Django en un archivo zip, django.zip
   
3. Remover del archivo zip los módulos no soportados/no necesarios, como la consola de administración, los archivos de traducciones locales (obviamente excepto español e inglés)
   
4. No olvidar adicionar los módulos en contrib que requiere el "ayudante" que son: auth, sessions, sites.
5. Copiar el zip al directorio raíz de la aplicación
6. Con el "ayudante" no es necesario hacer nada más, desde que el nombre sea django.zip

Eso fue todo lo necesario para armar un proyecto base generico para todas las próximas aplicaciones a desarrollar en Google App Engine (con suerte muchas) con Django y Dojo.

Obviamente se supone que en el futuro van a salir versiones nuevas de todos estos componentes y para entonces muchos de estos problemas se habrán solucionado. Aprovechando que toque el tema del futuro estoy intrigado por el soporte a un nuevo lenguaje en tiempo de ejecución según el roadmap publicado (mi predicción esta entre PHP y Java). De todos modos en el poco contacto que he tenido con Python me he sentido muy cómodo y veo grandes fortalezas en este lenguaje. Por otro lado, creo que el proyecto dojango va a evolucionar hasta convertise en el comprehesivo Zend_Dojo de Python brindando muchos otros "goodies" que estoy seguro facilitarán el desarrollo de apps en Dojo y mejorarán la productividad.

Me gradué de Maestría

Como algunos de ustedes ya saben, oficialmente soy Magister en Ingeniería área de Sistemas y Computación de la Universidad de los Andes. Quiero darle las gracias a todos aquellos que me apoyaron y confiaron en mí en el camino hacia este logro.

Ahora vienen nuevos retos y es el momento de empezar a aplicar en la industria todo lo que aprendí en la Academia.

Media Maraton de Bogota

Aca están las fotos de la media maratón de Bogotá el pasado domingo 27 de Julio de 2008.



Este es el mapa del recorrido


View Larger Map

Los primeros siete kilómetros se caracterizaron por el calor, estaba haciendo un sol increíble y creo que no hice la mejor selección en cuanto a la camiseta, sin embargo logré llevar un ritmo constante en cuanto a pulsaciones (70 bpm) del kilómetro 7 al 10 aprovechando el trayecto plano de la 72 hasta la 100 por la Cra. 15 fue más fácil aún y la hidratación empezó a mostrar sus beneficios; resultado, a los 10Km llevaba 55 minutos lo cual era la meta planeada.

Desde ahí todo fue inercia hasta el kilómetro 14, donde empezó el dolor en las rodillas luego de ver al "pacer" de las 2:00h, a propósito muy buena la idea ya que es la primera vez que hay de esto en la maratón, los "pacers" o "liebres" son atletas profesionales que saben exactamente cual debe ser el ritmo constante para demorarse X tiempo. Continuando con el recorrido, desde el kilometro 15 hasta el 21 fue el sufrimiento puro, el dolor no me dejaba acelerar aunque de pulsaciones andaba bien (entre 60 y 65 bpm). Opino que la ubicación de la meta es estratégica por la rueda samsung del parque del salitre, la cual puede ser vista desde varios kilómetros antes. La emoción al llegar fue inmensa y gratificante aunque el tiempo no haya sido el mejor fue una prueba lo suficientemente dura tanto física como mentalmente.

Eforcers en Google I/O. Moviendo la Web hacia adelante desde Colombia. Día Uno

Eforcers LTDA, la compañìa para la cual trabajo, como parte de la estrategìa de desarrollo de productos sobre Google Apps me envìo a la conferencia màs grande de desarrolladores de Google, la primera versiòn de Google I/O. Se llevò a cabo en la ciudad de San Francisco en California durante los dìas 28 y 29 de Mayo en el centro de convenciones Moscone West. La conferencia fue bastante interesante en cuanto a la calidad en el contenido de las sesiones, instalaciones en las que se llevò a cabo y presentadores. Pero tal vez màs importante que todo esto fue la oportunidad de escuchar y hablar a los ingenieros de Google y de otras empresas e interactuar con ellos.


Dos de las personas que tuvimos el honor de conocer allì fueron Dylan Schieman y Alex Russell de Sitepen fundadores de Dojo, el paquete de herramientas para Javascript que usamos en Eforcers desde el año 2005. Ellos fueron tan gentiles de invitarnos a una cena el dìa anterior donde compartimos varias experiencias, opiniones y pensamientos acerca de Dojo y la conferencia en general. No siendo suficiente con esto, estuvieron a nuestro lado gran parte del tiempo libre y nos presentaron gente respetada en la industria. Gracias a Alex pudimos asistir a una fiesta de WordPress, la plataforma para publicaciòn de contenido, donde conocimiento al fundador de esta compañìa y a varios usuarios de esta popular herramienta.

Volviendo a la conferencia, fue fundamental haber ido tres ingenieros de Eforcers (Andrès Cifuentes, Jorge Forero y yo) màs Julian Amaya de TechPyme, ya que eran alrededor de 90 sesiones, muchas de èstas simultaneas, y fue imposible asistir a todas. Sin embargo nos dividimos y se seleccionaron las sesiones màs acordes con nuestra nueva estrategìa y productos o de mayor visiòn hacia la direcciòn futura de Google. A continuaciòn presentò un pequeño resumen màs mis comentarios personales acerca de cada sesiòn que asistì.



Keynote Dìa 1.
El vicepresidente de ingenierìa Vic Gundotra tocò varios aspectos relacionados con las ventajas que traìa el uso de la "computaciòn en nube" comparandola con enfoques pasados como la terminal bruta y el computador de escritorio; centrandose en cuatro variables agrupadas en dos grupos: poder vs. accesibilidad y despliegue vs. funcionalidad. Luego hizo enfasis en otros aspectos importantes para la computaciòn en nube como la conectividad y el enriquecimiento de clientes web. Fue sorprendente cuando aclarò que mejores aplicaciònes Web traerìan mayores ingresos a Google ya que màs personas usarìan su motor de bùsqueda, definitivamente honesto. Luego cada uno de los gerentes de los principales productos mostraron el estado de sus proyectos e hicieron algunos anuncios importantes, como los APIs para manipulaciòn de imàgenes y cachè para el Google App Engine y la disposiciòn de este mismo a cualquier persona con cuenta de google accounts. Tambièn hablaron algunos usuarios de tecnologìas Google como el CTO de iLike y el de MySpace.


Estado de Ajax. Por Dion Almaer y Ben Galbraith de Ajaxian.
Definitivamente la presentaciòn mejor hecha de toda la conferencia, como buenos expertos en interfaces gràficas Dion y Ben realizaron diapositivas bastante amigables y llevaron la sesiòn en forma de charla mutua.

Los principales puntos que tocaron se resumen en la problemàtica de la trancisiòn entre experiencia para el desarrollador, interacciòn y experiencia para el usuario. El uso de librerìas y "toolkits" para reutilizar el conocimiento colectivo de la comunidad en tendencias, optimizaciones e infraestructura, limitaron la selecciòn a cuatro: Prototype+Scriptaculous, jQuery, Dojo y GWT mostrando sus diferencias y caracterìsticas. Tambien profundizaron en la nueva versiòn de HTML, Gears, integraciòn de servicios web con ambientes de escritorio, computaciòn en nube, entre otros.

Fireside Chat con el equipo de GData APIs
Una sesiòn con dinàmica muy diferente a la anterior, consistìa en un Q&A a los ingenieros desarrolladores del API. En esta sesion tuve la oportunidad de hacer preguntas especìficas a mis proyectos sobre Google Apps como sugerir el API para Docs y Presentations, consejos para hacer mi propia implementaciòn de Web Services a la GData, problemas existentes en el provisioning, entre otras. Obtuve muy buenas respuestas y sentì que habìa aportado retroalimentaciòn valiosa a ellos.

Can We Get There From Here? por Alex Russell
Similar a la primera sesión esta presentación fue increible, el expositor y líder del proyecto Dojo Toolkit hizo un estado del arte en el espectro de las herramientas para desarrollo Web de clientes principalmente en Javascript y HTML. Algunos de los aspectos importantes que tocó fueron el papel fundamental tanto de los cuerpos de estándares como de los implementadores de navegadores y el límite de responsabilidades entre ellos y nosotros como desarrolladores Web. Hizo un recuento de tecnologías y frameworks según el nivel de riqueza gráfica de las aplicaciones Web empezando desde puro HTML estandar hasta GWT, Flash y Silverlight. Por último habló de temas más enfocados a modelos de negocio y economía de Internet; como cuestiones de competencia vs. monopolios; finalizó mostrando algunas opciones para innovar sin estar atado al control de vendedores, sistemas operativos o estándares, igual (Google) Gears.

Underneath the Covers at Google por Jeff Dean
Revisión a la historia del crecimiento de la infraestructura de sistemas en Google desde los noventas hasta hoy, resumen ejecutivo del uso de tecnologías desarrolladas en casa como GFS(Google File System) MapReduce y BigTable. Políticas internas en cuanto a manejo y organización de equipos de desarrollo, uso de proyectos open source, filosofía de ser abiertos e implementar mejores prácticas de la ingeniería de software como revisiones de pares y pruebas unitarias. Por último mostró el trabajo actual que están llevando a cabo en cuanto a la comunicación entre data centers. Recomiendo ver este artículo en Webware.



Parsing and Generating KML with Google's KML Library por Michael Ashbridge
Vista detallada a la nueva librería libkml para hacer parsing de archivos KML 2.2, recientemente aprobado por la OGC como un lenguaje estándar oficial OpenGIS. Definitivamente es interesante el enfoque del desarrollo de esta librería ya que tuvo un proceso inverso a muchos otros productos, nació de código real en funcionamiento (dentro de Google Earth) y fue la implementación de referencia para soportar el lenguaje. Es una librería hecha en C++ pero gracias a SWIG hay encadenamientos a Python y Java. La librería se divide en cuatro partes: dom, engine, regionator y util. Michael explicó mediante demos varios ejemplos de utilización del API, aproposito bastante poderoso. En cuanto al futuro de esta librería este es el roadmap: estabilización del API, soporte completo a dom, plantillas, estilos y soportar más lenguajes.

After Hours
Tal vez la fiesta más costosa y espectacular en la que haya estado en mi vida, comidas y bebidas buenísimas por todos lados, además muy orientada a nosotros los ingenieros: pantalla gigante para jugar Wii, motos de arcade, air hockey, etc. Se presentó Flight of the Conchords, la banda neozelandesa de Folk y fue muy divertido. Google sabe como consentir a sus desarrolladores.





Actualización. 12/06/08. Los videos de las sesiones están disponibles en YouTube.

PDFs en Google App Engine

Tal como había mencionado en el post pasado el proyecto en el que estoy trabajando en el Google App Engine requiere la generación de documentos en formato PDF dinámicamente. En java alguna vez use iText y me pareció una muy buena librería con un API bastante flexible y poderoso. Siendo nuevo en python, decidí buscar proyectos open source similares que resolvieran esta problematica y tratar de entender cómo lo hacen.

El primero que encontré y el más popular fue ReportLab seguido de un tutorial bastate básico (lo que nosotros llamamos el "Hola Mundo") de como usarlo, ya que los ejemplos incluidos en la distribución son muy complejos de entender para un principiante como yo. Así que decidí intentar extrapolando los conceptos del tutorial a mi proyecto con tan mala suerte que todo terminó en una excepción de entrada/salida. Despues de leer cuidadosamente el stack-trace me dí cuenta que estaba trantando de acceder al sistema de archivos, operación específica que restringe el app engine.

Aprovechando que en el mismo proyecto uso Django como framework para el desarrollo de mi aplicación decidí incluirlo como un término de la búsqueda, de esta manera encontré esta página de documentación que fue clave en la solucion del problema ya que trataba al request HTTP como un archivo. Hice los ajustes necesarios al código fuente y probé, con tan mala suerte que me volvió a salir una vez más una excepcion de entrada/salida. Muy extraño, no? Ante la frustración decidí escribir en el Google Group la pregunta y de paso ver si alguien ya había resuelto este problema antes.

Antes de recibir cualquier respuesta y apelando al escepticismo de que todo el conocimiento está en el Group decidí incluir app engine como término de búsqueda, inesperadamente encontré exactamente lo que necesitaba. Luego de algunas pruebas y de identificar el gran error que había cometido la generación del archivo PDF fue exitosa. Ahora les presento el código fuente:

import cgi
import wsgiref.handlers
import logging

from google.appengine.api import users
from google.appengine.ext import webapp
from google.appengine.ext import db

import os
from google.appengine.ext.webapp import template

from reportlab.pdfgen import canvas
from reportlab.lib.pagesizes import letter
from reportlab.lib.units import cm, mm, inch, pica

class FinHandler(webapp.RequestHandler):
def get(self):
# Crea el objeto HttpResponse con sus encabezados apropiados
self.response.headers['Content-Type'] = 'application/pdf'
self.response.headers['Content-Disposition'] = 'attachment; filename=archivo.pdf'
# Crea el documento PDF usando el pedido como "archivo" y de tamaño carta
p = canvas.Canvas(self.response.out, pagesize = letter)
y = 750
# Escribe el titulo
p.drawCentredString(letter[0] / 2, y, "titulo")
....
#Salto de pagina
p.showPage()

#Guarda y limpia el documento PDF
p.save()