Tag python - Userlinux.net

Y el primer proyecto con Django se ha hecho realidad. Bueno para ser sincero creo que hace como un par de semanas que lo he subido a producción pero no he tenido demasiado tiempo para escribir sobre ello.

Como comenté hace unos días, uno de los principales motivos por los que me he decidido a profundizar un poco más en el mundo de Python ha sido lo divertida que resultó esta prueba de fuego con Django. Empezó como un juego por ver las bondades y malicias del framework del que todo el mundo hablaba y acabó siendo un micro-proyecto open source.

La idea era reemplazar el antiguo paster de código de PHP a Python + Django, algo sencillo de modelar y sin mucha complejidad en la lógica para comprobar los engranajes de la nueva combinación. El resultado no ha sido escandaloso pero sí divertido -que era lo que se pretendía-, podéis verlo funcionando online y colaborar activamente a través de su repositorio en BitBucket.

Ahora que ya he roto ese miedo escénico a publicar algo de código, espero que se trate solamente del primero de muchos repositorios públicos que aceptan colaboraciones open source.

No es que haya avanzado demasiado pero si algo me ha quedado claro despues de 15 páginas de buceo en este nuevo lenguaje es que todo en Python es un objeto. Mark Pilgrim no se cansa de repetirlo las veces que haga falta.

Una vez instalado en todas las máquinas desde las que estoy siguiendo el curso (ha sido sencillo porque ya estaba instalado) he escrito mi primer programa:

def buildConnectionString(params):
    """Build a connection string from a dictionary of parameters.

    Returns string."""
    return ";".join(["%s=%s" % (k, v) for k, v in params.items()])

if __name__ == "__main__":
    myParams = {"server":"mpilgrim", 
                "database":"master", 
                "uid":"sa", 
                "pwd":"secret" 
                }
    print buildConnectionString(myParam

Y hemos aprendido a declarar funciones, a llamar a objetos, lo que es el doc string, como importar archivos para utilizar sus funciones, la correcta indentación del código, etc. El siguiente paso será tener claros los tipos de datos (tuplas, diccionarios y demás), lo que es el módulo de __name__ ==" __main__" y como utilizarlo.

Todo en menos de media hora y con telecinco de fondo, así que tiene el doble de mérito. Si no se quieren perder... sigan buceando con nosotros.

Este mediodía he ido a por mi primer paquete de Amazon, se trataba de un lujo de dos libros sobre mi nueva aventura. La verdad es que -siendo sinceros- cada día que pasa me aburre un poco más programar en PHP como un autómata y era la única forma de atacar esa pasividad ante un nuevo lenguaje de programación:

• Dive into Python
• The definitive guide to Django

¿Por qué Python y Django?, pues ha sido una elección bastante sencilla, después de valorar varias alternativas me apetecía algo que realmente fuera RAD y que tuviera una extensa documentación que poder llevarme a la boca. Tenía dos opciones: Python y Ruby así que, tal vez por madurez del proyecto, por influencias directas como Borja, o por querer empezar "la casa por el tejado"... decidí validar de una vez el "order" y ponerme a bucear, me explico.

El argumento de "la casa por el tejado" tiene una explicación algo más racional. Hace algunos días y para comprobar el funcionamiento de Django puse en práctica un ejercicio habitual, migrar una mini aplicación de PHP a este nuevo framework. El experimento salió mejor de lo que pensaba -aunque eso da para otra anotación- pero lo más importante es que resultó divertido y no puedo negar que me ayudó a decantarme a favor del pony.

Sea como fuere intentaré desenpolvar y sacarle brillo a la experiencia de empezar de nuevo desde cero con algo. Y aquí estará este humilde sitio para contarlo, si queréis :).

Django nos ofrece un muy buen sistema de usuarios y ACL ya integrado en su código -builtin-, y no es nada complicado aprovecharlo para nuestras aplicaciones, es más yo diría que es ideal y está pensado para ello.

Si queremos guardar en una tabla el usuario que ha realizado según qué acción, en el modelo hemos de indicarle que habrá un campo con clave foránea a Users de Django (models.py):

class Entry(models.Model):
    title = models.CharField(max_length=200)
    user = models.ForeignKey(User)

Si dejamos el código así, a la hora de crear una nueva Entry desde el admin nos sacará un combo preguntándonos a qué usuario corresponde el registro, pero como lo que queremos es aprovechar la sesión que hemos iniciado -en el admin- para cubrir automáticamente esos datos, tendremos que indicarle -en admin.py-  y a la hora de guardar -save_model- que no queremos cubrir ese campo puesto que hay que cogerlo de la sesión abierta:

class AdminEntries(admin.ModelAdmin):
    exclude = ('user',)

    def save_model(self, request, obj, form, change):
        obj.user = request.user
        obj.save()

Una vez hemos guardado el registro podemos comprobar que efectivamente ha sido así si tenemos el campo user en el list_display del administrador de la clase.

Cuando -en programación web- queremos un campo del tipo slug habitualmente es porque tenemos un valor que pensamos convertir en url o similar, el ejemplo más claro lo podemos ver en este blog, con el título de cada entrada y la url de la misma:

• Django: los campos tipo slug -> django-los-campos-tipo-slug
• Dovecot, pequeñas peculiaridades -> dovecot-pequenas-peculiaridades

Los slugs (los de la derecha) se adaptan a url's canónicas que todo el mundo puede  visitar, sin caracteres raros ni ningún otro tipo de mala influencia para la gran G.

Django ya había pensado en ello y por eso tiene un tipo de datos SlugField, en general si a la hora de modelar la base de datos tomamos algo de tiempo para hacer las cosas bien nos ahorraremos mucho código. Veamos un poco de models.py para hacernos una idea de como queda el invento:

class Entry(models.Model):
    title = models.CharField(max_length=200)
    slug = models.SlugField() 

Definimos el campo slug como SlugField como habíamos dicho y dejamos que la magia se ocupe del resto. Por otro lado en la parte de administración debemos decirle que ese campo se tiene que rellenar de forma automágica con el contenido sluggeado del campo title. El correspondiente código de admin.py:

class AdminEntries(admin.ModelAdmin):
    prepopulated_fields = { 'slug': ['title'] }

Una vez hecho ésto tan solo nos queda ir al admin y probar que funciona, si configuráis el campo slug como visible veréis que según vamos escribiendo en el input del title se va generando el slug. Poco más de 5 lineas para tener la funcionalidad básica de un slug lista para usar en Django.

Ahora que ya sabemos instalar Zope es hora de sacarle partido a algunos de sus productos más famosos. Zope es un servidor de aplicaciones hecho en Python. Tenerlo instalado nos puede facilitar el desarrollo de webapps sin embargo nuestro siguiente paso será instalar aplicaciones ya creadas y probadas: los productos.

Los pasos a seguir -de forma genérica- no pueden ser más lógicos. Primero descargamos el producto seleccionado, luego lo descomprimimos en el lugar adecuado y reiniciamos el servidor. Empecemos, por ejemplo, con Zwiki.

Como en la vida tiene que haber de todo y -aunque no sea lo mío- parece que estoy abocado a ser un picateclas más, intentaré hacer mi estancia un poco más agradable probando algún otro lenguaje de programación distinto al de siempre.

Al no tener -creo- condición de caracter dominante me dejo llevar por los gustos de Borja cuando habla de los encantos de python y su servidor de aplicaciones: Zope, con lo que haremos nuestros primeros pinitos -instalación y poco más- en este nuevo mundo.

Si deseas aprender Python o empezar a manejarte con algunas de las herramientas basadas en este lenguaje (Plone, Zope, Zwiki, Django...) sigue leyendo.

Borja acaba de lanzar un llamamiento a todo el que quiera asistir -aquí en Lugo- a unos cursos, eventos, charlas... relacionados con este lenguaje de desarrollo.

Desde aquí solo pretendo darle eco a la noticia para que llegue al mayor número de personas interesadas, si estás interesad@ lee la entrada original y apúntate en los comentarios. Yo ya lo he hecho.

Este mediodía me dio por hacer un update de Breezy a Dapper en una máquina no demasiado importante, después de cambiar el sources.list lo puse a trabajar. Como suele pasar en estos casos, apt tenía que descargar bastante cantidad de paquetes de la red así que me puse a otra cosa echándole un vistazo de vez en cuando. En una de estas me encuentro con:

Configurando appres (1.0.0-0ubuntu1) ...
Configurando beforelight (1.0.1-0ubuntu1) ...
Configurando bicyclerepair (0.9-4ubuntu1) ...

Algunos administradores se preocupan demasiado de sus sistemas, otros como yo lo llevamos lejos de la obsesión. Pero ambos buscamos que la estabilidad sea la nota predominante en el trabajo (tan importante o más que la eficacia, aunque van de la mano).

Para que un sistema se mantenga estable hay diversos factores influyentes, desde el sistema operativo, la máquina, las medidas de seguridad impuestas a todos los niveles (físico y lógico)... no voy a dar ningún sermón sobre ISO porque ni por asomo soy el más indicado para ello.

A nivel de software y desde un sistema operativo libre como Linux o cualquier sabor de BSD, hay muchas herramientas especializadas en proveer al administrador de la información necesaria para saber si el sistema es estable o eficaz, sin embargo a veces lo que buscamos es tan específico que no encontramos solución a la que adecuarnos.