Retomemos la entrada anterior donde se dejaba en el aire la pregunta de si nuestra herramienta, Delphi, nos permitia desarrollar aplicaciones rapidamente e intentemos coger el toro por los cuernos (sin que nos de un buen revolcón):
Jose Manuel Navarro, en los comentarios anteriores, llevaba bastante razón al decir que existen herramientas que no son de proposito general y que dan un excelente rendimiento para las tareas o tipo de trabajo para las que han sido diseñadas. El hablaba de PowerBuilder. Me lo creo.
Nico tambien aporta esa dosis de realismo que nos hace tanta falta para hacer este tipo de razonamientos. Y efectivamente, no existe menos seguridad en agarrarse a Codegear que a Velneo, o confiar mas en Microsoft que en Codegear.
Pero permitidme que sigamos el hilo de razonamiento: Cuando uno llega a Velneo y se enfrenta por primera vez al editor de codigo (de esta empresa gallega) realmente se encuentra confuso y tira mano de la documentación. Los que venimos de Delphi buscamos referencias que nos ayuden a situarnos en los objetos que aparecen en las distintas ventanas. Intentamos buscar el inspector de objetos o la paleta de componentes y descubrimos en esas primeras correrias por el interfaz, algo similar al diseñador de relaciones de Access. Así que concluimos: -será como Access, donde establecemos el diseño de la base de datos y las relaciones entre las tablas.
No. Velneo no es Access. Para nada. Está muy por encima. Eso queda descubierto una vez que se exploran las primeras peliculas donde se explica como montar tu aplicacion por que ¡Y PRIMERA COSA IMPORTANTE!: Es la misma empresa la que está interesada en que sus programadores sepan utilizar correctamente su herramienta.
Para ello existen varios tutoriales que describen las aplicaciones más básicas. Y por supuesto, se explica con cierto detalle los mecanismos que se deben efectuar para la modificación de las plantillas de negocio: una plantilla de gestion (compras/ventas), una plantilla de contabilidad, un tpv, etc… Existe incluso un catalogo de normas de estilo a seguir para desarrollar correctamente en Velneo.
Esto es un pequeño mundo aparte donde no existe el punto net y donde la misma aplicacion, sin hacer cambio alguno, podria trabajar indistintamente en modo local o cliente-servidor, ejecutandose bien en el servidor local, bien en el servidor de bases de datos (que por cierto ademas es servidor de paginas web, servidor ftp o incluso servidor de mensajeria. Un mundo donde existen los campos enlazados y los peregrinos nombres de punteros a hermano o punteros al abuelo, jeje 🙂 (lo siento pero me coge la risa -sin malicia- cuando pienso en algunos nombres que han escogido).
Y sin embargo… lo dicho: funciona y por lo que dicen (yo no lo he comprobado) es robusto y fiable. El servidor de aplicaciones hace copias en linea, programadas y gestiona los accesos a los usuarios de las aplicaciones.
Es decir y resumiendo un poco para no alargarme demasiado. Tambien podría escribir otras muchas razones de cosas que me disgustan de Velneo, que existen y no son pocas (y algunas de cierta importancia en mi opinión), pero lo que si es cierto es que el programador de esta herramienta se despreocupa de algunas tareas que el mismo sistema de trabajo le facilita (o le restringe).
Si os parece vamos a analizar algunas (permitirme por favor que exagere un poco):
El gestor de ventanas: Este punto es vital. Velneo se ejecuta sobre el servidor de aplicaciones o bien localmente pero el control de las ventanas es transparente para el programador. Aqui no le vemos preocupandose sobre si el puntero es nil o apunta a una dirección valida de memoria. El programador se preocupa tan solo de diseñar las relaciones entre las tablas para que la logica del negocio se mantenga íntegra.
¿Y delphi?
Nosotros somos el rey del pollo frito. Eso si: superfelices de ello. Gozamos de todas las posibilidades habidas y por haber, por decirlo de alguna forma. Podemos crear ventanas en tiempo de diseño, heredarlas, hacerlas modales y tambien no modales, podemos elegir entre seguir una linea mdi, sdi o incluso mdi y combinar ventanas modales con otras no modales de tipo sdi. Y ademas, tenemos la chuleria de decir antes de empezar el desarrollo de nuestra aplicación: -¡Pito, pito, gorgorito, a ver que tipo le aplico… ! 🙂
Algo similar sucede con los componentes. En Velneo no puedes elegir. Tienes los que tienes y si no te gustan, mala suerte. Lentejas, si quieres las tomas y si no las dejas… Mientras que nosotros nos replanteamos en cada aplicación no solo que componentes escoger sino que version de los mismo usar. Así que podemos tener una decena de aplicaciones y cada una de una madre y un padre. Y todavía dando gracias de que no se nos vaya al carajo el entorno y tengamos que reinstalar y buscar todos los componentes…
En Velneo tienes la base de datos integrada en el mismo editor. Eso permite por ejemplo que una vez diseñadas las relaciones entre las tablas y creados los distintos campos e indices, podamos visualmente generar los formularios con las casillas de edición y etiquetas asociadas.
Y yo pregunto: ¿alguien de borland se preocupo en su momento de actualizar y mejorar el Database Form Wizard que mantuvo desde las primeras versiones hasta Delphi 7? ¿Y por que no enseñar a los programadores a crearse sus propios wizards en el caso de que no usaran Paradox…? Misterios sin resolver.
El único wizar similar a ese lo vi en las web de Marco Cantú, dentro de las utilidades que se integran en el ide de Delphi. Y por desgracia no está disponible el codigo fuente.
Y si hablamos de las ToolsApi, jejeje… es terreno pantanoso. Puedes perder horas y horas hasta encontrar ejemplos y documentación correcta. Y no es de la empresa precisamente. Yo he encontrado algunos expertos interesantes en GExperts pero me parece triste no encontrar ejemplos claros en la documentación de Borland. A mi al menos no me vale eso de que ya existen algunos ejemplos en la vcl y que te pueden servir de referencia como leí en alguna parte de la ayuda.
Yo quisiera por ejemplo que mi IbDataSet pudiera ser capaz de arrastrar al formulario en tiempo de diseño el interfaz asociado a las casillas de edicion y etiquetas, y poder elegir previamente que componente voy a usar (no estar obligado de por vida al TEdit y al TLabel).
Y no hemos hablado de UML (jajaja). En Velneo no existe la herencia (al menos en la versión actual) ni el modelado. Olvidate de las funciones y de los procedimientos tal y como los entendemos desde Delphi…
Y así podría ir desmenuzando y una de las conclusiones posibles podría ser:
«EL PROGRAMADOR DE VELNEO OBTIENE EL MAYOR RENDIMIENTO A MEDIDA QUE CONOCE LAS PLANTILLAS PROFESIONALES… EL PROGRAMADOR DE DELPHI A MEDIDA QUE CONOCE SU ENTORNO DE TRABAJO»
Veamos el lado positivo de estos razonamientos.
¿Que medidas podría tomar para sacar mayor partido a mi entorno?
Una de las primeras podría ser adoptar un buen framework que nos permita desentendernos del diseño de nuestra aplicación para centrarnos exclusivamente en la creación de los distintos módulos. En la web de Developer Express existian algunos ejemplos muy buenos que hacian uso de la herencia y te explicaban un modelo que resultaba francamente atractivo. El modulo activo condicionaba el interfaz de la ventana principal a traves de la gestión de las «acciones» preinstaladas en un contenedor de la clase TActionList.
Si adoptas esta medida, tal vez tengas necesidad (como yo la he tenido) de repetir bastantes lineas de codigo en la creación de los nuevos módulos. Una opción es hacer uso del repositorio y (copiar/usar/heredar) del modulo deseado. Sin embargo esta opción no siempre se ajusta exactamente a nuestro esquema de trabajo. En muchos casos deberiamos tener nuestros propios wizards de creacion de modulos y proyectos. ¡Vaya, vaya…! Ya se empieza a complicar la cosa…
Metamonos de lleno en el modulo ToolsApi y conozcamos los distintos interfaces que nos permitiran acceder al ide de Delphi. Un sitio imprescindible para visitar es: http://www.gexperts.org/opentools/ donde encontraremos información de como crear nuestros propios expertos, que nos ahorran valioso tiempo y tener que recordar pasados muchos meses, que normas seguiamos en la creación de los módulos.
Si a esto, añadimos la creación de nuestro propio experto que sea capaz de rellenar de forma automática los campos de edición de la base de datos, bien en tiempo de diseño, bien en tiempo de ejecución. Y nos intentamos amoldar al uso de determinados componentes sin dejarnos llevar por modas pasajeras ni cambios indiscriminados, habremos ganado tambien un tiempo precioso (adoptar nuevos componetes implica en la mayoria de los casos estudiar durante bastantes horas su uso y su documentación, y creo que no siempre se justifica su cambio sino solo por moda de usar tal o cual componente. )
Y esto se aplica tambien a nuestra base de datos. Parecemos picaflor que todo lo queremos probar… jejeje 🙂
Y por supuesto, y ya para finalizar, adoptar cualquier sistema de informes que permita ser personalizado por el usuario y que no nos obligue a compilar la aplicación cada vez que el usuario desea mover medio milimetro la cabecera de la factura o cambiar el color de la misma a rojo brillante.
Se me podrían ocurrir muchos mas detalles pero veo que no acabaría nunca…
Quizás la moraleja que yo he sacado es que perdemos demasiado tiempo en decisiones que no afectan a la propia aplicación sino a nuestra forma de trabajo. Intentemos centrarnos en la lógica del negocio y no reinventemos la rueda en cada aplicación nueva o proyecto.
(Ojo…
Y conscientemente no he dicho nada del idioma… ¡eso de que nuestro entorno a estas alturas de la historia, no esté disponible en castellano y que la empresa no haya pensado en crear documentación en linea para nosotros, es para dedicarle bastantes lineas mas. )
Delphi Básico 
Ayer no me podía extender y habría dicho algo más en la misma línea que tú: que en Delphi hubo una «desconexión» pronto de la idea original y no se siguió en la misma dirección, sino añadiendo «cantidad» en vez de facilidad. Yo no pienso que las cosas tengan que ser como son. Pero aunque se me ocurren muchas formas de mejorarlas, no creo que sea necesariamente bueno hacerlo mediante «wizards» que sigan dependiendo de un entorno cerrado.
Para Delphi falta quizás la herramienta aglutinante que Eclipse ha sido para Java, hasta el punto de que CodeGear lo usa como plataforma y ha abandonado el núcleo original de JBuilder.
Aparte de eso, no hace falta para nada un «wizard» para implementar un sistema de generación de código por plantillas. Lo puedes hacer con PHP mismo, o con lo que tiene Delphi para web, si no quieres meterte en otro lenguaje. Hay también productos específicos, lo que me recuerda que tengo que preguntar a uno que iba a probarlo.
Me gustaMe gusta
Hola Nico:
Gracias por el comentario. Yo no lo hubiera expresado mejor y coincido contigo en que en algun momento se perdió como objetivo ahondar en la facilidad para deslumbrarse por la cantidad.
Respecto al tema del wizard, es tan solo un ejemplo, que me venia al pelo en la comparación con velneo. De hecho, en este entorno tienes infinidad de ellos para automatizar ciertas tareas: creacion de los distintos tipos de relaciones entre tablas, generación de interfaces prehechos a falta de completar los cuatro detalles de integracion con la aplicación principal, etc.
Un Wizard es tan solo un experto. Algo que uno deberia poder hacerse para automatizar ciertas tareas que resultan repetitivas. El tenerlo integrado en el ide puede ser una comodidad.
Y ¿por qué no tener integrado en el entorno un sistema de plantillas? Lo digo por decir algo.
Fijate una cosa: he visto que delphi 2007 trae integrado el tema de patrones o el refactoring. Me parece muy bien en cuanto a que puede aumentar la calidad del desarrollo. Lo que no estoy tan seguro es de si queda suficientemente explicado y se aporta documentación y ejemplos.
Te lo diré cuando me ponga en ello. Porque es una pena que algunas mejoras se pierdan porque el usuario no comprenda su uso, que creo que es una de las cosas que pasaron en otro momento con determinadas opciones que incluia Delphi en versiones anteriores.
Resumiendo un pooc: Lo realmente importante es que exista en la mente de los miembros de Codegear una motivación por mejorar esa «facilidad» a la que te referías. Lo voy a decir de otra forma mas clara: ¿Sabes cuando se si una aplicación que he desarrollado tiene usabilidad? Precisamente cuando me pongo en el lugar del usuario y la sufro. Es cuando me doy cuenta de que cosas le faltan y que cosas suspira el usuario. Así que le recomendaria al equipo de Codegear que se pusiera en el lugar nuestro, para comprender las verdaderas carencias del entorno. A veces el problema es la comunicación entre dos interlocutores que pueden pasar horas y horas hablando sin realmente escucharse.
🙂
Por cierto: ¿has tenido algun problema con tu pagina web? He intentado acceder pero parece desactivada. ¿Estas manteniendola?
Me gustaMe gusta
Anoche intenté actualizar el sistema y dio algún fallo, no sabía que no se viese. Voy a probar ahora. Lo de la integración, pues sí, es más cómodo. Pero insisto: aunque parece que van mejor que hace un año, yo no veo garantía de nada.
Al final la cuestión es que no puedes evitar que una gran parte del trabajo sea rutina, sea feo. Y te aseguro que puede ser mucho peor de lo que seguramente tienes por costumbre. Trabajar con buenas herramientas y con una buena organización es cuestión de suerte, que no aprecias hasta que ves cómo funciona el resto.
Me gustaMe gusta
Para mi, la facilidad (y velocidad) de uso de una tecnología (IDE, lenguaje, o lo que quieras) la resumo en «el número de bifurcaciones que el usuario se encuentra en su camino».
Es decir (y como bien dices en tu artículo): en Delphi tienes que estar continuamente decidiendo cómo quieres hacer las cosas dentro del grandísimo abanico de posibilidades que te ofrece. Eso hace que seas muy versátil, pero que te puedas equivocar en alguna decisión (y cuando te cuelas en un cruce, ya sabemos todos los difícil que es volver al bueno camino)
En otros entornos no tienen esos problemas: no te puedes equivocar porque no tienes posibilidad que decidir el camino. ¡¡No hay bifurcaciones donde te puedas perder!! El propio entorno sólo te da una opción, y esa es la que tienes que seguir.
Como tú dices: son lentejas…
En estos entornos tan específicos, el problema está en elegir bien la herramienta. Como elijas la herramienta equivocada, estarás frustrado continuamente, porque la propia herramienta te irá llevando por el camino que tú no quieres seguir (y encima, sin opción a réplica). Pero como elijas la herramienta correcta, estarás en un nivel mucho más alto, por lo que viejos problemas habrán desaparecido de tu cabeza (ni ventanas MDI, ni modales, ni SDI: ventanas a secas).
Anteriormente dije que Delphi no vale para aplicaciones de gestión. Rectifico: Delphi no vale, si lo usas tal cual viene de fábrica. Si dedicas (mucho) tiempo y esfuerzo a crear un framework específico para tu tipo de aplicaciones, entonces puedes trabajar de una forma mucho más «guiada».
Eso sí: para crear un buen framework para Delphi hay que dominar la herramienta y el lenguaje, tenerlos bien puestos y por supuesto, usar la herencia (:
Saludos
JM
Me gustaMe gusta