Programación

integridad referencial en claves ajenas

por

En la nueva versión de el Puchero he decidido tratar con rigor el tema de las claves ajenas y aplicar la regla de integridad referencial para claves ajenas. Estas son las reglas que voy a seguir:

  • Regla de los nulos: permitir valores nulos – en mi casi en blanco – en los campos que son clave ajena.
  • Regla de borrado: al borrar la clave primaria los registros que contengan ese valor de clave ajena se pondrán a nulo.
  • Regla de modificación: al modificar un valor de clave primaria la modificación se propaga a la clave ajena.

Una cosa que me parece especialmente mal resuelta es la aplicación de la restricción de modificación de la clave principal. El usuario puede haber cometido un error de tipografia, por ejemplo, y tener que modificar uno a uno los registros que contienen la clave ajena antes de permitir el borrado de la clave principal. Menudo latazo.

errores errores

por

Tras leer un artículo de Softinspain sobre errores recuerdo algo que he leido recientemente en El paradigma:

Despedir a quien comete un fallo es desperdiciar el valor de la experiencia.

Según el libro, en Microsoft se estudian continuamente los errores cometidos, no para achacarlos a nadie, sino para aprender de ellos.

c3compiler

por

Ayer hice el registro del compilador C3 de Bruno Cantero. El principal activo de C3 es su estabilidad. Por las pruebas que hice con la versión de evaluación, C3 es el compilador xbase de 32 bits más estable que hay ahora mismo en el mercado. Además es el más parecido a Clipper, con lo cual la migración de los sistemas desarrollados en Clipper a 32 bits es cuestión de dias. Por decirlo en plata, C3 se traga casi todo el código Clipper sin rechistar.

Manuel Calero ya ha migrado casi por completo GST+, su impresionante programa de gestión, a 32 bits con C3. Hace poco dijo que necesitaría un año para hacerlo y lo ha conseguido en cuestión de semanas. Hay una demo del programa que contiene versiones en 16 y 32 bits y se puede descargar del sitio web de Manuel.

Es posible que xHarbour sea más avanzado tecnológicamente que C3, pero lo que tengo claro es que ahora mismo pretender hacer algo con xHarbour es jugar con una caja de bombas. Es cierto que el despliegue de medios técnicos y humanos de xHarbour es impresionante, la web es una pasada, hay un montón de gente trabajando en el proyecto, cada dia inventan algo nuevo, pero… no lo veo claro. Es como estar haciendo una casa con todos los oficios metidos dentro: el electricista hace las rozas antes que el fontanero, el pintor pinta antes que el carpintero termine las puertas,… más de una vez hay que deshacer lo hecho y rehacerlo de nuevo. El poco tiempo que tengo para programar no puedo dedicarlo a hacer experimentos. Sorry, Patrick.

C3 es un clon de Clipper a 32 bits. No más, pero tampoco menos. Es cierto que C3 tiene carencias: le hace falta una buena lavada de cara a la web, la documentación está incompleta y alguna cosa más, pero creo que ahora mismo es la mejor opción. Yo voy a tomar ese camino. Tengo ya FWC3, que me regaló Antonio Linares por ajuste de cuentas pendiente, y mi intención es que este sea mi entorno de desarrollo durante este año.

componentes de terceros – desde allí

por

La otra cara de la moneda es dedicarse al desarrollo de componentes. Mientras que hacer software de gestión es algo, más o menos, al alcance de la mayoría de programadores hacer componentes es subir un peldaño más. Pero para hacerlos y atreverte a comercializarlos hay que tener valor, mucho valor. Comercializar un control supone poner tu trabajo en manos de un montón de personas inmisericordes que te van a exigir lo imposible.

Yo colaboré con Paco García en los inicios de Canalfive. Paco hacia los controles y yo la documentación y mentenía la web. Pero lo realmente complejo era el soporte. A Paco lo freían. Paco hacia tenedores y la gente los queria usar como cucharas. Y correo va y lio viene. Era increible. Además Paco nunca decía a nadie ‘esto no se puede hacer’ y había veces que para un usuario en partícular rehacía medio control. Una locura.

Yo no soy capaz de hacer controles. Alguna vez he hecho alguno muy simple y siempre he tenido que pedir ayuda a otra gente. En eso soy bastante torpe, y por eso no oculto mi admiración por los que son capaces de hacerlo. Muchas veces intento retocar algo de otra persona y a veces lo consigo, pero la verdad es que los controles no son lo mio. El tener el código fuente de un control para mi no asegura su continuidad. Además de tener el código tienes que saber donde meterle mano y hacerlo con delicadeza.

componentes de terceros – desde aqui

por

Una de las cosas buenas y malas que le puede suceder a un determinado entorno de desarrollo es que cuente con abundantes componentes desarrolladas por terceros. Es una cosa buena porque enriquece el entorno, y es mala porque demuestra que al propio entorno de desarrollo le faltan controles.

La existencia de desarrolladores de componentes de terceros también demuestra que el entorno cuenta con un amplio número de seguidores que hacen rentable que otras empresas o personas – los terceros – dediquen su esfuerzo a completar el entorno con nuevos componentes. Es evidente que no existe la misma cantidad de componentes para Fivewin que para Delphi, por poner un ejemplo, de igual manera que los programadores que usamos Five somos bastante menos que los que usan Delphi.

Cuando comencé a desarrollar software utilizaba muchos de los controles de la extinta CanalFive: su grid, folders, meters y su calendario. Ahora con xHarbour lo único que uso es el calendario, debido a que no he podido – mejor dicho no he sabido – migrar el grid, los folders de Fivewin ya son nativos y toman el aspecto de XP y el meter me dio unos problemas muy raros y decidí no usarlo en Colossus.

Con esto intento plantear uno de los mayores problemas que como desarrollador tiene usar componentes de terceros: que te vuelves componentesdeterceros adicto y te puedes encontrar con problemas de compatibilidad de los componentes al evolucionar el entorno de desarrollo, lo cual se agrava si el desarrollador del componente ha bajado la persiana.

¿ Y porqué bajan la persiana ? … continuará

apuntes de make

por

Después de una semana renqueante por culpa de una gripe, al visitar las news de C3 me encuentro con que Rodrigo Soto ha elaborado una exahustiva explicación de como usar la utilidad make para compilar y enlazar una aplicación. Está en http://apuntesc3.tripod.cl/tlink32/tlink01.html y está realmente bien explicado. Son esas cosas de las que mucha gente presume saber pero sólo están al alcance de unos pocos.

funcionamiento de i18n en xHarbour

por

Uno de los temas de los que ultimamente hablo con mucha gente es del i18n de xHarbour, de lo bueno y de lo malo que tiene y de cómo intentar dar soporte de internacionalización en Harbour o en C3. Ya hice un primer post sobre el tema, pero recapitulamos, pues creo que el personal está perdido.

La manera de acometer la i18n en xHarbour es utilizar la llamada a la función i18n() para las cadenas que queramos traducir que pasaremos como parámetro. Una vez hecho esto generamos una lista de cadenas que se guardan en un fichero con extensión .hil Para ello llamamos al compilador con el parámetro -j, algo así como:

\xharbour\bin\harbour colossus.prg  -jes_ES.hil -i\fwh24\include;\xharbour\include -n</p>



Con esto lo que hace el compilador es localizar todas las cadenas que están como parámetros de la función i18n() en el archivo fuente colossus.prg y las mete ordenadas en el fichero es_ES.hil. Esto lo hacemos para todos los fuentes de nuestra aplicación, con la particularidad de que el proceso es acumulativo, es decir que las cadenas del fuente se acumulan al archivo .hil. Por eso se aconseja borrar cada vez el fichero .hil y generarlo por completo.


Una vez tenemos el fichero .hil lo traduciremos al idioma que queramos usando la utilidad hbdict que se encuentra en \xharbour\utils\hbdict y al que pasamos como parámetros los archivos de entrada – que hemos generado previamente – y el de salida que guardará la traducción hecha y que el programa genera si no existe. Con este programa traducimos una a una las cadenas que se encuentran en el fichero .hil y lo guardamos en un fichero con extensión .hit. Desde dentro de nuestro programa lo único que haremos es decir en que idioma queremos que se muestren las cadenas con las siguientes instrucciones:


HB_I18NSetLanguage( "en_US" )
REQUEST HB_LANG_EN
HB_LANGSELECT('EN')</p>



Si no decimos nada el programa mostrará las cadenas tal como aparecen en las llamadas a la función i18n(). El fichero .hil no se incluye nunca en la distribución, ya que se trata de un archivo de trabajo que sirve como guia para realizar la traducción con el hbdict. Sólo incluiremos en nuestra distribucíón el archivo .hit del idioma en que queramos que esté nuestro programa.


Ventajas de este método:


    

  • Que está todo hecho y funciona bien, salvo algo que comentaré más adelante.
    • 

  • Si añades una cadena nueva al fuente, regeneras el archivo .hil y llamas a hbdict, este acopla el .hil nuevo al .hit viejo y unicamente tienes que traducir la cadena nueva. De alguna manera hbdict tiene memoria. No se cómo lo hace pero lo hace.
    • 

  • Los ficheros .hit se cargan internamente en arrays de manera que la ejecución del programa no se ralentiza. Además tiene un formato de texto bastante extraño y está a salvo de que nadie meta las narices ahí.
    • 



Problema: que al ser hbdict un programa en modo texto usa páginas de códigos con lo que si usas acentos abiertos y cedillas no hace bien la traducción. Esto me está pasando con la traducción de Colossus a catalán, y por eso estoy haciendo un programa en Windows similar. De momento bilingüa tiene esta pinta y cuando lo termine será una contribución a xHarbour y el código estará disponible.




La menera amanuense de hacer esto es meter las cadenas en un DBF con tantos campos como idiomas y cade vez que tengas que traducir algo tirar del fichero. El problema que veo es que tienes otro DBF en tu aplicación, seguramente esto será más lento que el sistema de xHarbour y que estás más expuesto a que te toquen la traducción con cualquier herramienta que abra DBF. Recordar que con el método xHarbour el .hil nunca se distribuye, por lo que no se puede usar hbdict para tocar a mano una traducción ya hecha.


¿ Opiniones ?

debate de ideas o sobre software y coches

por

Una de las cosas que me animó a hacer este blog es intentar promover un debate de ideas acerca de la programación en general y el uso de entornos xbase en particular. Los foros de consultas técnicas están muy bien para eso, para resolver dudas, pero siempre he echado de menos los debates de ideas sobre programación. Me encanta leer artículos sobre experiencias de programación, uso de metodologías… sobre cosas que no son estrictamente de programación, sino digamos del envoltorio. Me gusta mucho la web de Joel Spolsky, es algo que he dicho mil veces, donde igual se habla de programación pura y dura que de como diseñar una oficina para que los programadores estén agusto. Pagaría por leer algo asi en castellano. José Alberto Hernandis ha comenzado un blog sobre programación que va en esta linea, se llama softinspain y la verdad es que tiene muy buena pinta.

A veces pienso que los programadores somos como los mecánicos y el software que hacemos son coches. A muchos de nosotros sólo nos interesa el motor del coche, mientras que al que se monta en el coche lo que menos le importa es el motor y da más importancia a la habitablidad del coche, la comodidad, la tapicería y el maletero. Y nosotros con la cabeza metida en el motor todo el dia. Creo que los progamadores deberiamos prestar más importancia al coche en su conjunto y menos al motor. Por eso son muy importantes los debates de ideas, porque te hacen levantar la cabeza del teclado y mirar hacia el horizonte para saber hacia donde vas y no sentir que vas en una ola que no sabes donde se dirige.

Por eso me ha gustado el debate entre René y Carles en los comentarios al post fivewin.info, porque este tipo de debates es lo que yo quiero leer. René, Carles: muchas gracias.

En el blog hay abierto un foro de debate para que todos podais abrir hilos sobre cualquier tema que os interese.

editor de recursos de PellesC… ahora si que si

por

Hace algún tiempo hablé del editor de recursos de PellesC. El caso es que he estado intentando usarlo, pero hasta hoy no he dado con la manera de hacerlo y encajarlo con xHarbour. Comprobareis que soy un poco chapuza, pero creo que todo esto puede servirle a más de uno.

Hasta ahora usaba el editor de recursos de Borland C++ 5.01 y todo iba bien. Sin embargo no me gustaban varias cosas, pero principalmente que de vez en cuando me hacia una de indios y me dejaba inservible el .RC porque al salvar los recursos mezclaba las lineas de texto de los mismos y armaba una gordísima. Además me parecía una barbaridad tener instalado el Borland C++ 5.01 si realmente usaba para compilar xHarbour la versión gratuita del Borland C++ 5.5.

Con el editor de recursos de PellesC tenía basicamente un problema: no era capaz de leer los .RC que el editor de recursos de Borland pero si leía bien los .RES. Sin embargo al leer un .RES, salvarlo como .RC el compilador de recursos de Borland no tragaba y me daba error.

La solución a todo esto es un poco enrevesada, pero basicamente consiste en editar los .RC con el PellesC y usar su propio compilador de recursos para generar el .RES que luego el link de borland meterá en el ejecutable.

Lo primero es tener un .RES, abrirlo con el PellesC y guardarlo como .RC. Si te creas un .RC desde cero con el PellesC tambien sirve. Antes de compilar con el MAK de la aplicación hay que generar el .RES y esto se hace de la siguiente manera:

\pellesc\bin\porc /I\pellesc\include2 programa.rc

Como los ficheros de cabecera de PellesC están en varios directorios los he copiado todos a un subdirectorio que se llama include2… ya dije que era una chapuza.

Luego hay que editar el .MAK de la aplicación para decirle que no use el compilador de recursos de Borland y que enlace directamente el .RES que acabamos de generar. Esto se hace comentando estas lineas:

# Application directories & filenames ########################################
...
#APP_RC   = $(APP_RES_DIR)\$(APP_NAME).rc
...
# Borlanc directories & flags ################################################
...
#BORLANDC_RES_EXE     = $(BORLANDC_EXE_DIR)\brc32.exe
...
# Explicit Rules #############################################################
!if $(RES_FILE) == YES
#$(APP_RES) : $(APP_RC)
#   $(BORLANDC_RES_EXE) -r $**
$(APP_EXE) :: $(APP_RES)
@if exist $(APP_EXE) $(DEL) $(APP_EXE) > nul
!endif

Y con esto he desinstalado el Borland C++ 5.01. PellesC se puede descargar desde http://www.smorgasbordet.com/pellesc/. Si alguien prueba esto y quiere compartir sus experiencias estaré encantado de leerlas.

fivewin.info

por

Fivewin.info es – era – una de las mejores webs sobre Fivewin. Mantenida por Patrick Mast, recogía noticias sobre Fivewin, aportaciones del autor de la web y de otros usuarios a Fivewin. Desde hace meses está sin actualizar. Patrick tomó la decisión de participar empresarialmente en xHarbour.com y ha dejado de mantener la web, algo por otra parte totalmente entendible. En un futuro próximo xharbour.com pretende ser competidor de Fivewin con su propio GUI y Fivewin.info era uno de los puntales de Fivewin. Lo bueno de Fivewin.info era que tenía actualizaciones casi a diario y eso creaba un gran sentimiento de comunidad. Todos los fivewiners teniamos un sitio de referencia donde aparecían las noticias más importantes de nuestro entorno de desarrollo favorito.

Han surgido otros intentos de hacer portales basados en lenguajes xbase como Olivares2000 y Puertosur, pero, siento decirlo, no es lo mismo. Quiza sea porque estos dos sitios están restringidos a usuarios en español, pero desde que Fivewin.info dejo de actualizarse parece como si hubiera menos usuarios de habla inglesa de Fivewin o es que los que hay hacen menos ruido que antes. Una cosa que no entiendo es porqué Antonio Linares no crea un sitio parecido… creo que es un error de estrategia monumental. Lo cierto es que Fivewin ha perdido apoyos importantes y eso a la larga puede pasarle factura.

Una cosa que me hizo mucha gracia las primeras veces que visité Fivewin.info fue la foto de Patrick en la portada. Luego comprobé que era de mucha utilidad: en la reunión de Olivares2000 en Marbella iba hablando con Manuel Calero hacia la sala donde se iba a celebrar la reunión y vi dos hombres con bigote dentro de la sala. Uno era Patrick, lo conocí enseguida por la foto de su web, y le pregunté a Manuel quien era el otro. Me contestó: Antonio Linares. Vaya, pensé, conozco antes a Patrick que al padre de la criatura. Antonio, creo, no tiene ninguna foto en su web.