Django o la fábrica de churros

Programar aburre, porque tendemos a programar lo mismo una y otra vez. Así, muchos caen en la tentación de buscar en exceso maneras de reducir el código. Dijo Wirth que algoritmos más estructuras de datos igual a programas; y cabe añadir que en la mayoría de programación web, poco algoritmo hay- así que con definir el esquema de datos, poco más deberíamos hacer, ¿no?

Estos días me he encontrado frente a una web sencilla, pero que a mi juicio no era adecuada realizarla con un CMS (puede que en gran parte porque no he encontrado un CMS que me guste) y me he decidido a probar Django. Django es un framework Python cuyo lema es “batteries included”; alusión al hecho de que resuelve una gran parte de los problemas típicos de desarrollo web- cosa que certifico y a la que añado que los resuelve a mi gusto. El otro gran qué de Django es la interfaz administrativa que trae; mediante unas líneas declarativas, obtienes una web de gestión que permite añadir, editar, eliminar, etc. entidades del modelo de datos, reduciendo en una gran parte el trabajo que le queda a uno.

¿A parte de esto, qué otras virtudes tiene Django?

  • Vistas genéricas. En particular, lista/detalle sobre los modelos de datos, resolviendo correctamente paginación, ordenación, filtrado, etc. Tiene también vistas y maquinaria para hacer CRUD, que supongo funcionan bien pero que no he usado
  • Usa HTML/HTTP “correcto” sin hacer cosas raras, añadir Javascripts innecesarios, serializaciones raras, etc. Todo muy limpio
  • Está documentado. No llega al nivel de Java o Spring, pero desde luego, comparado con Rails y otras estrellas de código libre…
  • No usa generación de código. Odiamos la generación de código.

Pero también le encuentro algún que otro defecto:

  • Definimos los modelos en lenguaje “Django”. Está bien, pero no es “SQL-completo”. Hay modelos, restricciones, etc. que no podremos expresar en este modelo, como por ejemplo, claves primarias compuestas o “listas ordenadas” (relaciones 1-n con campo de ordenación). El lenguaje para consultas tiene las limitaciones típicas de todos los ORM.
  • No me gusta Python. Me gusta la sintaxis estilo C, y exijo grandes ventajas a los que la descartan. Me gusta el tipado estático, y no estoy seguro que haya mucha magia en Django que necesite realmente tipado dinámico. Me gusta que mi editor trabaje por mi.
  • El sistema de plantillas está muy bien, pero es “regular” y no “gramatical”, con lo que no admite expresiones donde debería ni otras estructuras muy convenientes. JSP con fragmentos de tag es *muy* superior
  • Tengo la sospecha que el funcionamiento sobre JVM no será para tirar cohetes. Además, si nos interesa funcionar sobre JVM, nos tenemos que limitar a Django 1.1 y evitar 1.2 de momento.
  • En general el sistema de internacionalización está muy bien, pero no soporta internacionalización en el modelo de datos (i.e. campos multilingües en las entidades)
  • No viene con nada para hacer Javascript/AJAX, aunque seguramente no sería de mi agrado, claro

A pesar de esto, creo que es el mejor “framework completo” que he visto. Como plataforma “básica”, sigo prefiriendo Java + Spring + Servlets + JSP + JSTL, pero creo que Django puede tener un lugar bastante importante en el arsenal de un desarrollador web. La pregunta es, ¿cuál es ese lugar?

En mi opinión, Django ofrece una velocidad de desarrollo elevadísima para proyectos pequeños y medianos (siempre que no nos topemos con alguno de sus problemas). Para cosas gordas y/o que no encajen bien en Django, es lo de siempre; ¿hacerlo de cero o partir de un framework? Hacerlo de cero lógicamente es más tiempo, pero uno acaba conociendo intimamente la plataforma que hace y está toda a su gusto; usar un framework nos puede ahorrar tiempo, pero al hurgar dentro, a saber qué nos encontramos. Sospecho que las entrañas de Django están muy bien, pero… la decisión sigue siendo difícil. Mi poco amor por Python hace que probablemente yo no vaya a a apostar por Django más que para proyectos rápidos, pero intuyo que para muchos será una decisión más que acertada.

Vulnerabilidades en instalación por defecto de osCommerce v2.2 RC2a

Una pequeña nota para compañeros del gremio:

Una instalación por defecto de la última versión de osCommerce (v2.2 RC2a) contiene agujeros de seguridad en la configuración por defecto que permiten a un atacante adquirir control sobre la tienda

Aparentemente la práctica recomendada es aplicar los consejos de seguridad explicados en este mensaje en un foro, el agujero de seguridad está detallado en este otro mensaje del mismo foro y como guinda, comentaré que existen consultoras que trabajan esta tienda que no están al tanto de este agujero.

JCR, Modeshape, programación web en general

Una cosa muy habitual requerida de un programador es realizar páginas web. La programación web, a un nivel muy alto, particularmente se preocupa de dos cosas:

  • Generar contenido- usualmente HTML– en respuesta a una petición HTTP para una URL. Es decir, cuando en nuestro navegador introducimos http://www.google.com, los servidores de Google nos responden con un HTML con la página de búsqueda de Google.
  • Procesar formularios. Tecleo la entrada de este blog en el interfaz de administración; cuando le doy a “Publicar”, los datos del formulario se envían al sistema de mi blog, que los procesa y los introduce en la base de datos del blog.

Hoy nos ocuparemos, en parte, de lo primero.

¿Cómo almacenamos el contenido de nuestra web?

Una primera aproximación sencilla es guardarlo en el sistema de archivos. Algo tan sencillo como guardar el HTML en carpetas del servidor funciona casi sin esfuerzo- simplemente le decimos a nuestro servidor web que para cada petición HTTP busque un fichero con la misma ruta y nombre que la petición y lo sirva al usuario.

Lógicamente, normalmente esto no es suficiente. Por ejemplo, no queremos repetirnos continuamente con la cabecera y pie de nuestra página web en cada HTML que creamos. Aquí, cosas tan sencillas como los server-side includes, el PHP o cualquier cosa con directiva “include” puede bastar.

Otro problema que plantea esta alternativa es su falta de versatilidad. Una evolución lógica (y popular) es guardar los contenidos en una base de datos, típicamente una que use SQL (básicamente, una base de datos relacional). Creamos un esquema de datos de la información que queremos mostrar en nuestra página (por ejemplo, entradas de blog, usuarios, categorías, etc.) y programamos una serie de páginas que, en función de la URL que nos piden, recupera la información de la base de datos y crea un HTML con esa información.

Esta mecánica es profundamente popular, y una parte muy significante de la web actual está implementada de esta manera.

Sin embargo, la opción más popular, las bases de datos SQL, no son apropiadas para todos los contenidos que queramos mostrar en una web. Las bases de datos suelen representar datos altamente estructurados, con esquemas rígidos (es decir, un usuario tiene un nombre, email; una entrada de blog tiene título, autor, fecha de modificación, cuerpo, etc.), y los sistemas de presentación web basados en bases de datos SQL suelen ser por consecuencia, rígidos. Esto en muchas ocasiones no es especialmente problemático, en otras es fastidioso pero soportable y en ocasiones, puede ser muy incómodo.

Lógicamente surgen alternativas a las bases de datos SQL; el movimiento NoSQL abandera a toda una serie de bases de datos no relacionales que se oponen a usar SQL. Normalmente, por motivos erróneos y en gran medida motivados por la existencia de MySQL, probablemente la menos relacional y SQLifica base de datos popular que existe.

Por mucho que uno opine que la mayoría de argumentos que esgrimen los defensores del NoSQL, uno sí piensa que pueden existir cosas mejores para almacenar contenidos para web. Una tecnología interesante en este sentido es Java Content Repository, un mecanismo de almacenaje de información muy adecuado para el contenido web. Unas cuantas características de los repositorios JCR son:

  • Jerárquico. Los contenidos (nodos) de JCR se organizan en una jerarquía, directamente identificable con la jerarquización típica de las URLs del contenido web
  • Versionado/con espacios de trabajo. Podemos almacenar todas las versiones que vayan habiendo del contenido, y disponer de varios espacios de trabajo paralelos (e.g. el espacio de trabajo público, un espacio de trabajo de borradores, etc.)
  • Con metadatos. Podemos almacenar metadatos sobre el contenido (autor, fecha de publicación, etc.) de una manera flexible

Así pues, en principio, JCR parece un sistema muy útil de cara a almacenar información web. Lo interesante de JCR es que es sólo una API, con varias implementaciones. Así, un repositorio JCR podría guardar su información en una base de datos SQL, en una NoSQL o en cualquier cosa que se le ocurre al implementador.

Y es aquí donde aparece Modeshape de JBoss. Modeshape es un JCR cuyo almacenaje es flexible. Más bien, JCR es una librería para implementar JCRs. Podemos implementar JCRs que cojan los datos de una base de datos, de otro JCR, de una fuente de datos NoSQL, de lo que sea. Y también nos permite unificar varios JCRs y acceder a ellos como si fueran uno.

Esto es harto interesante. Muchas aplicaciones web quieren recoger datos de diversas fuentes- algunas preexistentes y otras que se crean ad-hoc para la aplicación web en cuestión. Mediante Modeshape, podemos unificar el acceso a estas fuentes de dato, creando un adaptador a JCR que nos permita acceder a todos los datos que requerimos presentar vía web, mediante un mecanismo especialmente adecuado para su presentación web.

Para completar una aplicación web- o al menos su parte de presentación de contenidos, sólo necesitaríamos añadir algo que exponga el repositorio JCR que creamos a la web, lo cual sería algo interesante a comentar otro día.