featured image

En estos días he estado más volcado en Python y Django. Quizás sea por acercar un poco más y mejor a lo que hace gente como Demonware, o quizás sea por puro vicio. Lo dejo a opinión popular :-P

El hecho, es que llevo unos tres años desarrollando en Rails (no cada día pero sí de forma más o menos asidua), y me interesé en ver qué tenía de bueno Django que pudiese aprovechar en algunos proyectos en lugar de hacerlos todos siempre en Rails, no porque Rails no me guste, sino porque, desde el punto de vista de administración de sistemas, sí es verdad que Rails es más pesado de instalar y mantener que Django (Python).

A vista de pájaro

En principio, la página web oficial de Django ofrece una gran información con tutoriales y un manual muy completo sobre el framework. El tutorial que ofrece da un repaso completo a la base de Django y te permite introducirte de forma rápida en el framework.

Lo primero que sorprende, es que la generación del proyecto base son ¡4 ficheros! El fichero de configuración (settings.py), el fichero de administración (para los comandos de consola y demás, manage.py), el fichero de rutas (urls.py) y el típico fichero __init__.py para indicar que el directorio es un paquete.

Otra de las cosas que cambian con respecto de los sistemas rails-like es el concepto de aplicación. En Django pueden existir, para un proyecto, varias aplicaciones, y cada aplicación está lo suficiente encapsulada como para poder instalarse en cualquier proyecto.

Esto quiere decir que podríamos crear (o instalar) una aplicación para blog, otra para foro y otra para galería de fotos, por ejemplo, y esas aplicaciones se podrían seguir usando no solo en ese proyecto, sino también en otros.

El tema de las rutas es muy parecido a todos los demás sistemas que he visto, salvo por el tema de que puede fraccionarse de modo que cada aplicación pueda tener su propio enrutado. El enrutado es por URI, por lo que no tiene nada que ver con dominios y se pueden establecer bases, para cuando se cargue una aplicación, que sus URIs se completen anteponiendo esa base.

Una de las cosas que más sorprende, que he visto en casi ningún framework, es una interfaz de administración configurable. Con gestión de usuarios, grupos y perfiles de usuarios por defecto, así como un sistema scaffold para poder gestionar los datos de los modelos que se quieran administrar, con la posibilidad de definir, incluso, la forma en la que se presentarán los campos.

Por último, el tema de los modelos, tiene como buena base el hecho de que se define cada tabla en cada fichero específico de modelos dentro de cada aplicación, y con un simple syncdb desde consola, el sistema lee la definición de los modelos, la definición de las tablas en la base de datos, y realiza las modificaciones pertinentes. En este sentido, parece mucho más claro y limpio que las migraciones de rails, o la generación de modelos de doctrine.

Rendimiento

No he podido aún realizar las pruebas que lo verifiquen, pero dada la fuente, le daré credibilidad como para describirlo o comentarlo al menos. Según parece, el rendimiento de tres frameworks comparados con las mismas pruebas e incluso optimizaciones, resulta que Django queda a la cabeza, justo delante de Rails y finalizando la lista Symfony.

Esto realmente me ha asombrado bastante, ya que consideraba que PHP, en este sentido, e incluso usando extensiones como APC, sería mucho más rápido que Rails y Django. No obstante, hay que tener en cuenta ciertos aspectos claves. El primero, es que, por ejemplo, Rails, cachea el código compilado de los modelos, controladores y vistas en el demonio que sirve las páginas, de modo que cada ejecución aislada, cada petición, hace uso de ese código listo para ejecutarse.

Lo mismo sucede con Python, en general, se pueden ver ficheros con la extensión pyc, que indican que el código se ha compilado y queda listo para su ejecución directa.

Entonces, ¿por qué odio Django?

No, no lo odio, es el título de una presentación que hizo Cal Henderson en el Djangocon de 2008 con ese mismo título (pero en inglés): Why I hate Django?

En sí, es un gran forofo de Django y Python, su conferencia termina siendo más una parodia que una crítica real, y viene motivada por tres factores:

  • El equipo: humano que realiza Django. Lo critica porque, comparado con el creador de Stuts (que tiene... ¡¡¡barba!!!), o el equipo de Rails (que se puede comparar a Michael Knight), el equipo de Django lo compara o ve como si fuese un grupo de música o algo sin forma... vamos, que no se vende bien.
  • El lenguaje: ya que no es una moda, el lenguaje tiene algo que preocupa a los programadores, y es que no se pueden hacer cosas como con un lenguaje serio, como Perl (que es organizar el código a su forma)... Python restringe el formato de escritura y no está de moda como Ruby, Haskell, Erlang o Scala.
  • El framework: tenemos a Struts (estructuras), tenemos a Rails (raíles), ... tenemos a Django... ¿sin logo ni mascota?... eso no es serio... aunque haya intentos de buscar mascotas como la de los ponies.

Una posible mascota para Django es el pony (más parecido a un pegaso de Barbie), junto al slogan: el framework web para ponies con poderes mágicos.

Conclusiones

Bueno, es domingo, lo único que puedo decir es que, junto con Rails, Django es uno de los mejores frameworks en los que he desarrollado y de los que más me gustan para la realización de interfaces web. El código resultante se basa en el concepto DRY, por lo que, si se sabe aprovechar al máximo la creación de aplicaciones, se puede llegar a ese punto que quieren llegar muchas empresas de hacer webs como churros.