med 3.0

Ya se encuentra disponible la versión 3.0 de MED, el editor de código fuente que uso habitualmente. Aunque hay características que no contempla para mi es un buen editor. En la web de Prometheus hay un artículo escrito por Adolfo Lagos Jiménez sobre cómo configurar el editor para convertirlo en un aceptable entorno de desarrollo.

Quiero empezar a familiarizarme con Eclipse, pues me han hablado maravillas de este entono. Lo instalé en mi PC pero no lo uso habitualmente, quiza abrumado por tantas posibilidades que tiene.

vcode, el regreso de CanalFive

vcode es un IDE para entornos XBASE, que incorpora las siguientes características:

  • editor de texto con lisbox de funciones, tooltips con sintaxis, grabación de macros, realce de sintaxis, busqueda en multiples ficheros
  • Gestor de proyectos
  • Asistente de makes, si se quiere o make automatico
  • Editor de formularios con editor visual de menus, editor barras de botones, y editor de barra de mensajes, visualizador de recursos
  • Wizard de clases
  • editores de imagenes y hexadecimal
  • posibilidad de trabajar con el compilador y el GUI que se quiera

El creador de vcode es mi amigo Paco canalfive, ¿ quien sino ? Ahora mismo está en fase de desarrollo y Paco quiere tener lista una primera versión estable para el verano. Pero Paco no vuelve sólo, trabaja con un equipo de programadores con la intención de establecerse como desarrolladores de componentes.

sobre runtimes y enlazadores

Esta año en mis clases en la UA tuve algunas discusiones con alumnos acerca de programación. Una de ellas fue sobre el runtime de la plataforma .NET. La verdad es que nunca me ha parecido que tener un runtime de 20MB sea el colmo del progreso.

En su artículo Please Sir May I Have a Linker?, Joel Spolsky habla sobre el tema. Una de las cosas que dice es que los runtime son peores que las DLL. Asi que si antes hablabamos del infierno de las DLL, ahora no se de que tendremos que hablar. ¿ Del purgatorio de los runtimes ? Quiza habría que volver la mirada atrás, a la época de los compiladores puros y replantear la situación.

Esta semana estoy en Valencia en un curso de administración de redes Novell. Alli he coincidido Jesús Fernández, un compañero de trabajo de Murcia que tiene un interesante fotoblog y al que debo un enlace. El jueves hemos quedado para cenar los asistentes al curso y espero que Jesús tome fotos y las publique.

Ya le pillaré alguna 😉

integridad referencial en claves ajenas

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

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

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í

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

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

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

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:

1\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:

1HB_I18NSetLanguage( "en_US" )
2REQUEST HB_LANG_EN
3HB_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 ?

alanit
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.