4 bits blog

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“.

Hace ya bastante tiempo en el trabajo me tocó lidiar con un programa (en C) que debía procesar la configuración de un archivo INI, para quién no lo sepa es un archivo de texto con un formato similar a este:

;Archivo INI

[sección]
clave1=valor1
clave2=valor2

En estos casos lo mejor es no reinventar la rueda, así que hice un par de búsquedas por internet, pero lo que encontré no me gustó, así que ni corto ni perezoso realicé mi propio cutre-parser que funcionaba bien para lo que quería, archivos INI creados a mano, pero no para todos los casos que podría tener un archivo INI.

Así que gracias a un poco de tiempo libre me he puesto las pilas un poco y he ido modificando aquel cutre-parser hasta algo más decente, aunque todavía le quiero dar un par de vueltas para dejarlo bien. De todos modos, el código que hay ahora mismo funciona bastante bien, así que he creado un repositorio para mini en github (por cierto, git mola mil), así no tenéis excusa para probarlo.

En el anterior post de introducción a django, no se usaron bases de datos, así que en este se verá cómo trabaja django con las bases de datos, es algo realmente sencillo.

Los modelos

Al basarse django en el MVC, divide la aplicación en dos partes la vista (que ya se pudo ver en el anterior post) y el modelo. El modelo define los datos que utilizará la aplicación, como podrían ser los datos de un usuario (nombre, apellidos, dirección, …).

En el caso de django, los modelos serán clases de python que heredarán la clase Model y que utilizarán unos tipos de datos especiales para definir sus atributos. Más tarde, django, gracias a su ORM, transformará estas clases en tablas de la base de datos del proyecto.

Leer el resto »

Voy a recuperar otro de mis documentos perdidos en Google Docs (el anterior fue el de las autotools), esta vez se trata de un pequeño manual sobre cómo proteger las contraseñas de lo usuarios de cualquier aplicación que se programe, el manual es una traducción al español del artículo How to encrypt user passwords de Daniel Fernandez.

1. Visión general

Casi todas las aplicaciones web modernas necesitan, de un modo u otro, cifrar las contraseñas de sus usuarios. Se podría decir que, desde el momento en que la aplicación tiene usuarios, y los usuarios se identifican usando una contraseña, esas contraseñas se deben guardar usando algún tipo de cifrado.

Hay muchas razones básicas para esto: las bases de datos pueden estar comprometidas, y por tanto también las comunicaciones. Pero la razón más importante es que se tiene que pensar que las contraseñas de los usuarios son datos personales. Sus contraseñas son sus claves para su privacidad, por tanto son personales, y nadie tiene el derecho de conocerlas. Y se debe cumplir esto si se quiere ganar la confianza de los usuarios.

Leer el resto »