A raí­z de empezar a utilizar EurekaLog, una herramienta que recomiendo a todo el que se dedica a hacer programas en Delphi, me he dado cuenta de la cantidad de excepciones que lanzaba dentro del código de PhotoGestión solo para cortar la ejecución, esas excepciones las capturaba el EurekaLog y eso generaba una cantidad enorme de informes de error sin sentido.

Opciones de Eurekalog

Me he tirado 4 horas quitando todos los raise exception y cambiándolos por un aviso y un Abort. He dejado solo las excepciones de las que realmente me interesa enterarme.

Hablando del EurekaLog, es una maravilla de utilidad. La hemos configurado para que desde el ordenador del usuario nos enví­e un correo con el error, la captura de pantalla y un fichero que cuando lo abres te lleva a la lí­nea exacta donde se ha producido dicho fallo. Pero se puede utilizar para que enví­e el informe de error a un BugZilla, al FogBugz o al Mantis.

Vamos una forma muy buena de pulir el programa.

IBAN es el acrónimo de International Bank Account Number, es una norma por la cual se identifica una cuenta bancaria de cualquier pais (aunque de momento sólo se utiliza en Europa). Más información en la wikipedia

Hoy he tenido que modificar una aplicación que prepara un fichero XML para enviar a un organismo público, en ese fichero habí­a que indicar el código IBAN de unas cuentas bancarias. Resulta que donde esta aplicación tienen como 50 cuentas bancarias y además hay que indicar cuentas de terceros. Tenemos los digitos de entidad, oficina y cuenta de cada una, pero no el IBAN. He buscado información y he visto que como se calculaba, me he puesto manos a la obra y este es el resultado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

{--
Devuelve el código IBAN que corresponde con la cuenta y el paí­s que se le pasa
Ver http://www.desarrolloweb.com/articulos/2484.php y http://www.sima.cat/chkiban.php
--}
function ControlIBAN(const Cuenta, Pais: string): string;
var
  i, j: integer;
  m: int64;
  l: TInteger;
  t: string;
  s: string;
 
  function LetterToDigit(const C: Char): string;
  const
    a: char = 'A';
  var
    d: byte;
  begin
    result := C;
    if C in ['A'..'Z'] then
    begin
      d := (byte(C) – byte(a)) + 10;
      result := IntToStr(d);
    end;
  end;
 
begin
 
  l := TInteger.Create;
  try
 
    t := Cuenta + Pais + '00';
    s := '';
    j := Length(t);
    for i := 1 to j do
      s := s + LetterToDigit(t[i]);
 
    l.Assign(s);
    l.Modulo(97);
    l.ConvertToInt64(m);
    i := 98 – m;
 
    result := IntToStr(i);
    if i < 10 then
      result := '0' + result;
 
  finally
    l.Free;
  end;
 
end;
 
function FormateaIBAN(const Cuenta, Pais: string): string;
begin
  result := Pais + ControlIBAN(Cuenta, Pais) + Cuenta;
end;

Requiere la librerí­a DFF

Pruebas

Hemos realizado las primeras pruebas de rendimiento con InstantObjects.

Inicialmente hice un port del broker de IBX para poder utilizar las MDO para acceder a Firebird, y con ese realice las primeras pruebas. He de decir que me quede decepcionado, bastante, por el rendimiento: 2 minutos para crear 3000 artí­culos, cuando lo mismo haciendo simples INSERTs habí­a tardado 45 segundos. No esperaba que el rendimiento fuera igual, pero tampoco tan lento.

Entonces me he puesto a buscar información y he leí­do que la librerí­a de acceso a Interbase/Firebird UIB es rápida, y como en InstantObjects viene un broker para UIB, pues nada a probar.

He realizado el mismo test, con el mismo equipo y el resultado ha sido fantástico: 29 segundos, más rápido que MDO de forma directa.

Voy a continuar investigando, no vaya a ser que UIB tenga alguna pega.

Problema con la clase base

Ahora la pega la tengo en el modelo de clases, al crear una clase que es la base de todas, interesa que todas tengan unos determinados atributos y métodos.

Resulta que en la base de datos se crea una fila en la tabla por cada objeto creado en cualquier clase descendiente, con lo que a poco que se trabaje la tabla de la clase base tendrá cientos de miles de filas, y millones en un par de años, con los consiguientes problemas de rendimiento.

Vamos a ver como podemos conseguir por una parte tener la clase base, por otra que no se cree la tabla correspondiente, pero que las clases herederas si tengan los atributos de la base.

En fin, continuaremos informando.

Actualización 16/03/2007
Ye he solucionado lo de la clase base. Simplemente tení­a que decirle que no la almacenar, tan sencillo como eso, pero torpe de mi no lo veí­a, no se que narices estaba buscando.

Si hace un año escribí­ Malas noticias para Delphi, esta semana han llegado noticias esperanzadoras, parece que CodeGear, la nueva empresa que se está haciendo cargo del entorno y lenguajes de desarrollo de Borland, tiene las cosas claras, saben lo que hay que hacer y lo están haciendo. Fenomenal.

Leyendo a Marco Cantú me he enterado que están a punto de lanzar un nuevo Delphi 2007 for Win32 y un sorprendente Delphi for PHP que en Arcadina nos va a venir fabuloso para tener un único entorno de desarrollo para las dos plataformas con las que actualmente trabajamos: Windows e Internet/LAMP.

Entonces, hace un año, me plantee buscar alternativas, estuve mirando y probando varios lenguajes y entornos, pero ninguno me convenció, así­ que decidimos dejar pasar el tiempo a ver que ocurrí­a, parece que, de momento, fue una decisión acertada.

Acabo de leer en BitWise que Borland acaba de anunciar su intención de vender los IDEs de desarrollo a otra empresa, centrándose en soluciones de gestión del ciclo de desarrollo de aplicaciones (ALM)

Si bien esta noticia era mas o menos esperada no deja de ser una mala noticia.

Personalmente llevo muchos años desarrollando con Delphi, y me he resistido a cambiar a otros entornos porque, principalmente, el lenguaje en sí­ me gusta mucho y estoy muy comodo, y además porque .NET no me acaba de convencer.

Vamos a esperar a ver que ocurre finalmente, pero son tiempos difí­ciles para Delphi. Parece que esté tocado, esperemos que no lo suficiente como para hundirlo.

Si, como parece finalmente se vende esa parte de Borland, esperemos que los nuevos propietarios pongan las ganas suficientes para llevar a Delphi al futuro.

Ya viví­ hace tiempo algo similar, y terminó mal, muy mal, hablo de Clipper, cuando Computer Associates lo compró a Nantucket, hablo de cuando habí­a MS-DOS y llegó Windows para cambiar el panorama del desarrollo de aplicaciones. Ahora se vuelve a repetir la historia, llega .NET y provoca una revolución.

¿Tendremos que caer en las herramientas de Microsoft? ¿No hay alternativas para el desarrollo en Windows? ¿Será verdad que es mejor un entorno soportado por una comunidad de software libre que un entorno propietario? ¿Volveré a xBase? Un mar de dudas es lo que tengo, otra vez.