desarrollo


Soy un firme defensor del software libre desde hace años. Incluso estoy muy orgulloso de haber formado parte como becario de la Oficina de Software Libre de la Universidad de La Laguna. Desde que fundamos Galotecnia Redes Sistemas y Servicios hemos estado muy ocupados tratando de hacernos un hueco en el pequeño y competitivo mercado canario.

Como empresa trabajamos principalmente con Django, que en este tiempo ha crecido muchísimo. Trabajar con Django nos aporta muchas ventajas como por ejemplo no tener que compilar cada vez que queremos probar una modificación o poder trabajar con un lenguaje, Python, que posiblemente se acerque al equilibrio entre expresividad y rendimiento.

El hecho de que cada vez más y más gente esté trabajando con este framework hace que haya disponible cientos de líneas de código al alcance de la tecla. Esto es magnífico ya que te permite concentrarte en lo que hace distinta a tu aplicación.

Hace tiempo que no puedo picar código a gusto por distintos motivos, pero hoy he podido un poco. He estado trabajando en hacer cosas con la aplicación administrativa. La aplicación administrativa es bastante flexible y permite hacer cosas bastante chulas con bastante sencillez.

Controlar las entradas que se muestran a un usuario (código de django-blog-zinnia modificado) :

def queryset(self, request):
"""Make special filtering by user permissions"""
queryset = super(EntryAdmin, self).queryset(request)
if request.user.has_perm('zinnia.can_view_all'):
return queryset
return Entry.objects.filter(blog__in = request.user.blog_set.all())

El truco está en que el request tiene un atributo user, por lo que básicamente se pueden hacer muchas cosas muy interesantes.

Restringir las opciones de una ForeignKey:

def formfield_for_foreignkey(self, db_field, request, **kwargs):
if (request.user.is_superuser == False) and (db_field.name == "blog"):
kwargs["queryset"] = Blog.objects.filter(authors = request.user)
return db_field.formfield(**kwargs)
return super(EntryAdmin, self).formfield_for_foreignkey(db_field, request, **kwargs)

Nuevamente tenemos el usuario en el request, en este caso es un poco más engorroso porque tenemos que filtrar por el nombre del campo, pero sigue siendo sencillo y potente.

Restringir las opciones de un ManyToMany:

def formfield_for_manytomany(self, db_field, request, **kwargs):
if (request.user.is_superuser == False) and (db_field.name == "related"):
kwargs["queryset"] = entries_published(Entry.objects.all(), request.user)
return db_field.formfield(**kwargs)
return super(EntryAdmin, self).formfield_for_manytomany(db_field, request, **kwargs)

Es básicamente lo mismo que en el caso anterior. Ojo este método no está documentado, por lo que no estoy seguro de que sea buena idea utilizarlo.

Con estas tres opciones y alguna que otra que no he comentado podemos hacer que el contenido que cada usuario ve en la interfaz administrativa sea personalizado a dicho usuario lo cual es necesario en muchas ocasiones.

EDITADA: Corregida la indentación y el el return del ejemplo de manytomany

Durante la formación para ser profesionales del mundo de la informática se enseñan metodologías de ingeniería del software para lo cual, normalmente se, enseñan con cierta profundidad procesos pesados (en contraposición a los ágiles) como métrica o UP. Las metodologías ágiles se suelen nombrar, pero no se profundiza mucho en ellas.

Nunca me han gustado las metodologías pesadas ya que considero que en la mayoría de los casos es más costoso seguir la metodología y escribir la documentación que desarrollar el proyecto.

En contraposición con todo esto existen las metodologías ágiles, que permiten utilizar un esquema de desarrollo mucho más natural.

Utilizando una metodología pesada el ciclo de desarrollo puede ser algo como:

  • Entrevista con el cliente para obtener requisitos
  • Convertir los datos obtenidos del cliente en una especificación de requisitos (doc1)
  • Hacer diagramas de casos de uso que contemplen todas las funcionalidades (doc2)
  • Hacer un montón de documentos más (Plan de pruebas,…)
  • Presentarle los documentos anteriores al cliente (que en muchas ocasiones no es técnico y no los entiende bien)
  • Desarrollar el proyecto
  • Desplegar el proyecto

En las metodologías ágiles se busca aligerar la carga que conlleva la documentación, pero también se consigue hablar de manera natural el lenguaje del cliente. El ciclo anterior podría ser:

  • Entrevista con el cliente para obtener requisitos en forma de ejemplos (se utiliza un lenguaje cercano al la lógica de negocio del cliente)
  • Convertir los ejemplos en tests (esto es código)
  • Desarrollar el proyecto verificando que pase los tests
  • Desplegar el proyecto

En el primer caso era necesario convertir en explícito los datos entregados por el cliente mediante multitud de documentos. Esto hace que, si los requisitos del proyecto cambian, sea necesario modificar todos los documentos generados con nuevas versiones que reflejen los cambios, con lo cual el coste del cambio va aumentando con el transcurso de los distintos ciclos. En este tipo de metodologías el contrato son los documentos.

En el segundo caso se evita generar documentos para explicitar los acuerdos, requisitos, etc, presentados por el cliente. Acuerdos, requisitos, etc. se reflejan en los ejemplos, que, una vez convertido en tests, son el contrato. Además el contrato es en sí mismo el plan de pruebas (o al menos una parte muy importante de este).

LLevo algún tiempo buscando un IDE completo enfocado en el desarrollo de aplicaciones con Django y hasta este momento todavía no he encontrado nada con lo que me sienta satisfecho. He probado Eclipse con Pydev, ERIC4, PIDA, Open Komodo, etc.

Lo que pido del IDE no son cuestiones tan complicadas:

  • Autocompletado (que funcione bien)
  • Posibilidad de lanzar el servidor de pruebas desde el sistema
  • Detección de errores
  • Integración con SVN
  • Integración con trac (esto es deseable)
  • auto importación de modulos (esto es muy deseable)
  • Ligero
  • Resaltado de sintaxis (tb en las plantillas)

Lo cierto es que lo que mejor se ajusta a lo que busco es Eclipse + Pydev, pero tiende a no autocompletar en el segundo . (self.conn.sim…) lo cual es una pena porque en mi código eso es muy habitual.

Tengo entendido que en la nueva versión de kdevelop se está trabajando en la posibilidad de escribir python y cuenta con un sistema de plugins que espero haga sencillo este tipo de tareas.

En otro orden de cosas me gustaría comentar que nuestra empresa ya tiene página web y que hace poco la Televisión Canaria mostró uno de los productos en un informativo. (El vídeo en youtube)