4 bits blog

Después de ver las vistas de django y los modelos de django, toca ver cómo crear formularios web para poder interactuar con los datos de la aplicación.

La clase Forms de django

Los formularios en django son clases que heredan la clase Forms del módulo django.forms, las partes más interesantes de este módulo son los:

• Widgets: son los elementos que forman un formulario, por ejemplo: un cuadro para la introducción de texto (<input type="text">).
• Campos: Son clases que representan el tipo de datos que tendrán las diferentes partes del formulario, de modo que al enviar el formulario se validarán que se introducirán ese tipo de datos. Por ejemplo: CharField indicará un campo de texto (como se puede ver es similar a los datos de los modelos).
  Además, los campos se transforman automáticamente en widgets que tienen asociados de forma predeterminada, o indicándoles el widget que se quiere usar.

En el caso que se ha venido realizando en estos posts, un formulario para introducir los datos del usuario podría ser:

# forms.py
#-*- coding: utf-8 -*-

from django import forms

class FormularioUsuario (forms.Form):
    """Formulario para guardar un usuario en la base de datos."""

    nombre = forms.CharField (max_length=40)
    apellidos = forms.CharField (max_length=40)
    email = forms.EmailField ()

Este formulario se podrá utilizar en la vista correspondiente de modo que cualquiera pueda introducir los datos de un usuario y que la vista los procese para guardarlos en la base de datos.

Leer el resto »

Hace unos días tuve que convertir un repositorio de subversion a un repositorio de Git. Después de buscar un poco por Google, encontré la manera de hacerlo en una web del wiki de Debian sobre cómo configurar Git en su web de proyectos Alioth.

Antes de nada, hay que crear un archivo con los nombres de los desarrolladores que han usado el repositorio de subversion, el archivo tendrá el siguiente formato:

pepe = Pepe Garcia <pepe@garcia.es>
juan = Juan Gonzalez <juan@gonzalez.es>

Los nombres de los desarrolladores del repositorio de subversion se pueden conseguir ejecutando:

$ svn log "svn://REPOSITORIO-SVN/" | awk -F'|' '/^r[0-9]+/ { print $2 }' | sort -u

Este archivo se debe guardar como «authors.txt» para que mi script lo localice, aunque no sería muy difícil cambiar mi script para que se le pase la ruta como pará.

Mi script «svn2git.sh»

Este script se descarga el repositorio indicado (usando git-svn) y convierte y/o borra todos los datos relativos a subversion, como las ramas, los tags, …

#!/bin/sh
# Converts a subversion repository to a Git one.
# git-svn must be installed.

if [ $# -lt 2 ]; then
   echo "Usage: $0 SVN-REPOSITORY LOCAL-PATH"
   exit 1
fi

git svn clone $1 --stdlayout --authors-file=authors.txt --no-metadata $2

cd $2 > /dev/null

for t in `git branch -r | grep 'tags/' | sed s_tags/__`; do
    git tag $t tags/$t^
    git branch -d -r tags/$t
done

git branch -d -r trunk
git config --remove-section svn-remote.svn

rm -fr .git/svn .git/{logs/,}refs/remotes/tags/

cd - > /dev/null

exit 0

En el anterior post sobre los modelos de django, se explicaba cómo se crean los modelos de datos que se usan con la base de datos, pero no se vio ningún modo de trabajar con ellos a parte de la consola de django.

Las vistas

Las vistas se encargan de la capa lógica de la aplicación web, esto es realizan las tareas necesarias sobre los datos recibidos y devuelven los datos necesarios para que se muestren en la web.

En el caso de django, las vistas son funciones de python que reciben un objeto HttpRequest y que devolverán un objeto HttpResponse. Estas funciones se relacionarán con diferentes direcciones de la aplicación web, gracias al archivo «urls.py».

Leer el resto »

Para los que programen en C con Visual Studio y sientan añoranza de valgrind, aquí están los pasos sobre cómo detectar fugas de memoria (memory leaks) en Visual Studio:

• Añadir la macro _CRTDBG_MAP_ALLOC del preprocesador, ya sea definiéndola en algún archivo del proyecto o en las opciones de compilación del proyecto.
• Incluir en el siguiente orden stdlib.h y crtdbg.h en los archivos dónde se busquen las fugas de memoria. El archivo crtdgb.h sustituye las funciones malloc y free por unas propias que registran la memoria reservada y liberada.
• Añadir la función _CrtDumpMemoryLeaks () al final del programa en el que se buscan las fugas de memoria. Esta función muestra por la salida de depuración las fugas de memoria detectadas.

Todo esto sólo funcionará cuando el proyecto se compile con la macro _DEBUG definida, es decir, en lo que debería ser para todos la versión de depuración del programa.

La macro _CRTDBG_MAP_ALLOC sirve para que la función _CrtDumpMemoryLeaks () muestre información sobre el archivo y la línea en la que se produjo la fuga de memoria.

Un pequeño ejemplo de cómo quedaría todo:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

int
main (int argc, char *argv[])
{
    /* Código del programa */

    _CrtDumpMemoryLeaks ();

    return 0;
}

Si este programa tuviera alguna fuga de memoria, al compilarlo en modo depuración y ejecutar el depurador de Visual Studio, se obtendría en la salida de éste un listado con las fugas de memoria del programa.

Para más información, leed el artículo Enabling Memory Leak Detection de la MSDN.

Cuando empezaba a programar con C y C++ recuerdo los quebraderos de cabeza para comprobar que los valores “entraban” dentro de las variables y evitar desbordamientos problemáticos. Java solucionó esto haciendo que, si el valor se pasaba del rango de la variable, se reiniciaba el contador. Es decir, que si queremos poner el valor 212 a un fichero byte (-128 a 127), Java nos muestra en realidad -44.

Esto, que en principio puede parecer un gran avance porque evita problemas de seguridad en los programas (uno de los motivos por los que en Java no se pueden manejar punteros), al final se demuestra que es un nido de bugs. Porque 212 no son -44. Y esto puede ser un auténtico problema en algo tan visible como una fecha.

El mes de marzo es un mes muy especial. Su mes anterior es de longitud variable (28 ó 29 días) y el siguiente es de 30, siendo el propio marzo de 31. Ved el siguiente código:

Calendar cal = new GregorianCalendar();
cal.set (Calendar.DAY_OF_MONTH, 30);
cal.set (Calendar.MONTH, 2);
System.out.println (cal.getTime ());
System.out.println (cal.getActualMaximum (Calendar.DAY_OF_MONTH));
cal.set (Calendar.MONTH, cal.get(Calendar.MONTH) -1);
System.out.println (cal.getActualMaximum (Calendar.DAY_OF_MONTH));

Esencialmente, lo que hace es ponernos en 30 de marzo de este año y sacar por pantalla los siguientes datos:

• Fecha actual
• Número de días del mes de marzo
• Número de días del mes de… ¿febrero?

Java, en su excelsa sabiduría, ha decidido que en este caso que 2-1=2. Porque al restar uno al mes nos quedamos en 30 de febrero o, lo que es lo mismo, 2 de marzo. Esta chorrada (obviamente en un código más complejo) nos tuvo en el trabajo una mañana entretenidos porque el número de días de los meses siempre eran 30 ó 31, incluído un inexistente febrero.

En parte fue una suerte que estuviéramos a 30 de marzo y no en 2 de abril, en cuyo caso nos daríamos cuenta del problema casi un año después de sacar el proyecto a producción. A veces Java es realmente odioso con su “deja que la JVM piense por ti“.