Is in use right now in a few wholesale distributors but is time to make a international beta. I’m recruiting beta testers for this application.
In the first stage, I need developers with the knowledge in how make a integration with ERPs/Accounting/Financial software for validate the synchronization interface.
If you have this profile, want collaborate & release as open source your code, I invite you to subscribe here.
0 comments | 0 pingbacks | tags: bestseller, beta, delphi, python
Portando de FreePascal a Delphi (facilitar multi-plataforma)
Estoy en la fase de crear un mini-servidor de aplicaciones que se ejecutará en Windows & Linux.
He elegido a FreePascal como la herramienta para realizar la labor de portar el código de Delphi (Windows) a esta plataforma. Ya tengo resuelto los problemas mayores y el hecho de que librerias como la de RemObjects este ya portada a FreePascal es un gran alivio.
Sin embargo, siempre en el camino se van encontrando pequeños inconvenientes.
Una función importante del sistema, es su mecanismo de plugins, los cuales por múltiples razones (técnicas & aburridas) decidi invocarlos usando la tecnica “antigua” pero probada de encadenamiento de comandos y por ello necesito invocar de forma transparente scripts & ejecutables redireccionando la salida y los errores (stdin, stderror) de los comandos. Para los que no entiendan, es similar a abrir la consola del DOS y ejecutar “dir .” y capturar el resultado de pantalla, pero todo sin intervencion del usuario y sin que aparezca la ventana del DOS.
Hacer esto es muy simple. El ejemplo clasico se puede ver en este link. Y bueno, como hacerlo multiplataforma?
Se me ocurrio que ya que voy a portar el programa a FreePascal de todas maneras, pues mirar como lo hacen alli. Y encontre la informacion sobre la clase TProcess. Muy bueno y todo, pero ya que el IDE del FreePascal (lazarus) no es tan productivo como el de Delphi y que igual no he terminado el proceso de preparar el sistema para Freepascal me pregunte que tan viable era hacer una transferencia de codigo a la inversa: Del FreePascal al Delphi.
Y resulto ser mas fácil de lo que esperaba!.
- Bueno, primero se instala Lazarus desde la página oficial, el cual incluye el compilador FreePascal y el código fuente.
- El archivo que contiene la clases _TProcess _ esta en ´DIRECTORIO INSTALACION LAZARUS\lazarus\fpc\2.2.5\source\packages\fcl-process\src\process.pp´. (NOTA: La extensión .pp es la por defecto en freepascal).
- Copie el archivo process.pp & pipes.pp & la carpeta windows al directorio de la aplicación. Dentro de esta carpeta hay unos archivos .inc que son los que contienen el código especifico de cada plataforma, en este caso el windows.
- Ahora renombre los archivos .pp a .pas. Y copie el contenido de los archivos .inc dentro de cada .pas (por pura conveniencia).
- Ahora, borre la directiva {$mode objfpc} del inicio de cada .pas.
- Por último compilar y ver errores. Te saca que no encuentra unos tipos de datos (eje: DWORD), el cual se arregla fácil haciendo click derecho sobre el tipo, menu refactoring/Find Unit.
- Se corrige este código:
(Ubicado en pipes.pas):
Function CreatePipeHandles (Var Inhandle,OutHandle : THandle) : Boolean; begin Result := CreatePipe (@Inhandle,@OutHandle,@piInheritablePipe,PipeBufSize); end;
por:
Function CreatePipeHandles (Var Inhandle,OutHandle : THandle) : Boolean; begin Result := CreatePipe (Inhandle,OutHandle,@piInheritablePipe,0); end;
Y listo!
0 comments | 0 pingbacks | tags: delphi, freepascal
Crear una mejor experiencia para el usuario: Guia del Logo para Windows
No hay nada mas frustrante que cuando estas con el computador y todo sale mal.
La experiencia del usuario es la combinacion del Hardware + Sistema Operativo + Resto del software. Muchas veces se le hecha la culpa a los 2 primeros pero de forma frequente el problema real esta en el ultimo.
Son incontables las veces que frente a un problema con el computador la solución haya sido “Reformatear el equipo” debido a que el software en cuestion hace algo mal hecho.
Como desarrolladores tenemos la responsabilidad de hacer aplicaciones funcionales y que no frusten a la gente. Solo que muchas veces desconocemos que existen guias & buenas practicas a seguir para tal fin.
Estas operan bajo el umbral del “Windows Logo Program” que es una certificacion que da Microsoft a los productores de software (es cuando encontramos esas etiquetas que dicen “Certificado para Windows Vista” & similares) que delinea buenas practicas a seguir. Aunque la certificacion oficial tiene un coste elevado, nada impide el seguir las pautas que se delinean.
Entre ellas se encuentran:
- Forma correcta de instalar aplicaciones que funcionen sin permisos de administrador y no muestren el molesto aviso del UAC en Vista
- Como hacer apliaciones que operen de forma segura
El documento se puede descargar de aquí.
0 comments | 0 pingbacks | tags: delphi, programacion, windows
Mejorando los colores al editor de Delphi
Esta es la historia de como se amaestra a un elefante:
- Se captura de pequeño, y se ata a un arbol o poste con una cadena o cuerda. El elefantito ve que no se puede soltar.
- El elefante crece. Sigue atado al mismo poste o cadena. Pero ya dejo de intentar safarse…
Con las herramientas pasa lo mismo. Muchas veces uno asume que las cosas no se pueden cambiar, porque antes no se podia… o no se sabia como.
Una de las cosas que muchos programadores no se toman el trabajo de mejorar es el aspecto del editor de código. Lo cual es extraño, igual uno estara trabajando sobre el todo el tiempo.
Hace mucho salio este sitio:
que muestra diversos esquemas de colores para todos los gustos, optimizados para una mejor lectura… o solo porque a alguien le parece lindo ;).
El punto es que también se puede personalizar el editor de código de Delphi, solo que desafortunadamente no es tan intuitivo como parece, principalmente, porque el control que se utiliza en el dialogo de opciones para seleccionar los colores es una reliquia del windows 3.11 en cuanto a funcionalidad, lo cual seguro desanima a más de uno. Es su cadena que lo ata al arbol.
Pero hace mucho descubri como hacer el cambio — no proclamo ser el primero, sino más bien que algún día se me prendio el bombillito — y hoy quiero compartir el truco.
Primero, es necesario abrir el regedit y viajar a la carpeta:
HKEY_CURRENT_USER\Software\*CODEGEAR*\BDS\*VERSION*\Editor\Highlight
Nota: Reemplazar a Codegear por Borland y a Version por la versión interna del IDE de Delphi para ubicar la carpeta exacta. Si no sabe como, busque en el regedit por Assembler o Attribute Names que son nombres de las opciones en las opciones del Delphi para los colores del editor.
Allí se encuentran todas las opciones del editor de código y se pueden cambiar. Es importante notar que es mejor sacar un backup por si acaso (click derecho sobre HighlightExport), luego hay que buscar un esquema que te guste.
Para el mío, me baje a Intype que es un editor minimalista para programadores. En la carpeta donde se instala, en el directorio themes hay unos archivos con unos esquema muy buenos. Utilizando de referencia a pastels_on_dark.itTheme* y con la información descriptiva (pues, para un programador quiero decir!) que hay en esos archivos, emepza a modificar asi:
- En Delphi, elegi al esquema de color Twilight que es el único de fondo oscuro, y que sirve de base.
- Miro en el archivo *.itTheme el código hexadecimal del color (ej: background : ‘#211E1E’) y le cambio el simbolo # por $.
- Ahora, y esta es la parte molesta del proceso, es necesario ir a cada sub-rama de Highlight dentro del regedit y cambiar la opción Background Color New por el código hexadecimal $211E1E. IMPORTANTE solo hacerlo para los que estan preestablecidos como clBlack.
- Seguir ajustando las demás propiedades. Es casi obvio.
- Reiniciar el Delphi y ver que tal quedo todo. Igual por las opciones del Delphi se pueden hacer ajustes de ser necesario.
De esa manera, asi queda:
Espero que esto los anime a desatarse del arbol ;).
0 comments | 0 pingbacks | tags: delphi
El malabarista es reseller oficial de RemObjects
Durante mucho años he sido fan de los productos de RemObjects, tal como se ve en uno de los primeros post que hice.
Luego de una charla interesante con Marc Hoffman termine convirtiendome en reseller de toda la línea de productos de RemObjects.
Ahora bien, resulta que no soy un vendedor o comercializador, sino un desarrollador puro & duro, asi que al principio casi me da un shock la idea….
Pero luego de pensarlo veo que es una progresión natural. Y que puedo brindar la ventaja de realmente usar los productos en la vida real, aunado a más de 10 años de experiencia en proyectos de desarrollo multi-nivel, multi-base de datos e internet.
Por lo pronto, estoy armando la documentación en español antes de poder aceptar pedidos o de empezar a vender — de hecho, me pareceria criminal vender un producto sin documentación! -.
También estoy desempolvando mis habilidades con el mismo, ya que por razones de trabajo llevaba casi 2 años sin usarlo en serio — durante ese tiempo me pidieron actualizar unos programas a .NET — pero con agradable sorpresa veo que no ha cambiado mucho y que de hecho varias cosas, aunque pequeñas, se han simplificado o mejorado.
Estoy creando un programa para mi empresa que sera multiplataforma, tanto en Windows como en Mac OS X y posiblemente en Linux también. Asi que en la medida que tenga la plena confianza de lo que estoy usando ire compartiendo la información.
La documentación no sera una simple traducción al español de la ya muy completa información existente el sitio Web de RemObjects, sino una adaptación al mercado latino y al tipo de proyectos típicos que creamos al sur del planeta.
Si tienen alguna sugerencia de lo que les gustaria ver, solo pinchen comenten!.
0 comments | 0 pingbacks | tags: delphi, remobjects
Muchos creen que el mundo de software es solamente complicado por su código, ese montón de 0 y 1 o esa cantidad de líneas en un lenguaje de programación concreto.
Luego, a la hora de implementar o usar el software se descubre que es complicado por su uso, porque falla, porque no instala, porque se vuelve obsoleto, porque llueve y porque hace sol también.
Pero no termina allí. Es notoria la confusión en cuanto al licenciamiento, uso y distribución del software.
Por lo general se tiene la mentalidad de que:
Todo software comercial es costoso, monopolista y cerrado
y
Todo software “open source” es abierto, gratis y libre
Al igual que un programa típico esta compuesto de diferentes partes, la parte económica y social del mismo también. Suponiendo un software que se va a distribuir, por cualquier razón, un programa completo consta de:
Un(os) autor(es)
Bueno, todo código al final tiene uno o varios autores, quienes diseñan y programan el sistema. Por defecto, todo el material del programa le(s) pertenece(n) exclusivamente por la leyes internacionales de derechos de autor, a menos que de alguna manera hayan dado un paso al respecto.
Código fuente
Todo programa requiere código fuente, las instrucciones que se escriben en un mas-o-menos-comprensible-para-humanos lenguaje de computador. Este es el indispensable para poder corregir y mejorar el programa.
Código compilado
Otro programa se encarga de “compilar” o convertir ese código fuente en un sistema binario que pueda ser ejecutado por la máquina.
Archivos anexos
Como pueden ser los archivos de ayuda, imagenes y demás.
Licencia
El cual es el contrato de uso del programa.
Si un programa no tiene una licencia explicita, es difícil saber que hacer al respecto (como no soy abogado, no tengo idea, y la idea que tengo, me la guardo para que luego no me llame de la carcel alguien quejandose de mi consejo).
Por eso, si Ud. es un desarrollador y no especifica una licencia, por favor hagalo.
Una licencia ES UN CONTRATO. Es por eso que es tan complicado como cualquier otro contrato, y para muchos, incomprensible. Como muchos contratos, pocos lo leen y menos lo entienden, pero como también muchos atestiguaran, puede volverse en contra y patearnos en el hígado.
Por eso, es indispensable buscar asesoría legal al respecto. ¿La razón? Los abogados saben de problemas legales, incluso problemas que uno como programador o usuario NI SE IMAGINA.
Como desarrollador, AUN SI SE ELIGE UNA LICENCIA OPEN SOURCE, es una señal de responsabilidad revisar el mismo por un abogado, en especial si el software o sitio web o lo que sea va a tener distribución significativa o va a ser usado bajo serias condiciones (por ejemplo, al manejar dinero). ¿La razón? Las leyes varían de país en país y además — y es posible que las cláusulas de una licencia copiada de internet sean ILEGALES en el país.
¿Cuales? No se. Yo no soy abogado, ningún desarrollador sin experiencia legal esta capacitado para saber en que rayos se esta metiendo, de igual manera que un abogado sin experiencia en desarrollo podrá entender porque solo hay 10 tipos de personas en este mundo: Los que entienden binario y los que no (-i.e. si quedo en blanco es un chiste de programadores-).
Sistema de distribución
O sea, como se hace llegar al usuario final. Puede ser copiando archivos, imprimiendo el código en papel, descargando de un sitio, obteniendo el archivo binario, o el código fuente.
Al final se reduce en el “open source” que contrario a la creencia popular, nada tiene que ver con hippies que promulgan la libertad y el anti-monopolio, ni mucho menos significa “gratis”.
“Open source” significa “Código abierto” o sea, que se distribuye el programa en sus archivos fuentes para su posterior compilación, que es algo útil en manos de un programador y puede-que-si-o-no útil para el resto de la gente.
Y esta el “binary” (o: “código binario”) que no significa, como muchos creen, que las libertades de la gente estan negadas, que es monopolista y demás chorradas.
Solo quiere decir que el código esta “cerrado” porque el software esta compilado en archivos binarios, y por lo tanto a menos que seas un operador de la matrix, no entenderás todos esos caracteres raros.
Es por eso que al final todos los programas “open source” se transforman en “binary” de forma natural. SIN LA LICENCIA, no se puede presumir absolutamente nada acerca de lo que “open” y “closed” significa.
Un modelo económico
Entiendase por el mismo, como el mecanismo de integración al mundo real.
Puede ser por medio de pagar el diseño, el desarrollo, la entrega, la distribución, la capacitación, o puede ser pagando por todo o por ninguno de los anteriores (en economía, sea como sea, se “paga” el tiempo en emplear algo, en saber usarlo, en costos indirectos como la luz y el agua, etc… por eso es que no hay nada absolutamente gratuito).
Puede que haya una motivación intelectual, espiritual, monetaria, o similar, o todo junto u otras. El modelo económico no esta directamente ligado al software. Es por eso que hay software “cerrado” o “closed” que sale más barato que el “abierto” y al revés también.
Al final, el dueño del software debe mezclar todos los elementos para traducir un aburrido programa de computador en un producto, o sea, en algo que se puede usar, entender, distribuir y desechar. Asi que al final, es importante de parte y parte entender cuales son las motivaciones ecónomicas del programa y bajo que contrato (licencia) se da derecho al uso del mismo.
O puede que darle “siguiente siguiente” sirva también hasta que llegue la policia ;).
0 comments | 0 pingbacks | tags: delphi, open source, programacion, software
Grupo de usuarios Delphi/Afines Medellín / Colombia
Ya es hora de que los programadores de Delphi / Pascal / C# / C++ y afines usando tecnologia de Borland tengamos apoyo en Medellín.
Estoy armando un grupo de usuarios. Más info: http://www.clubdelphi.com/foros/showthread.php?p=160321#post160321.
0 comments | 0 pingbacks | tags: delphi, programacion
Ya se público mi segundo artículo: Programando al programador en el sitio de desarrolladores de CodeGear.
Trata sobre lo que es minimamente necesario para trabajar de forma organizada.
0 comments | 0 pingbacks | tags: delphi, programacion
Se publico mi primer artículo en CDN (CodeGear Developer Network) : Codificar para el cambio.
Es algo que escribi hace dos años, cuando era mas joven pero igual de feo. Espero les guste!.
0 comments | 0 pingbacks | tags: delphi, programacion
Ok, ahora vamos a hacer nuestro primer “servicio” o aplicacion multi/nivel. Pero antes que vayamos a programar como locos, es bueno prepararse un poco, mental y tecnicamente. Evitando trampas comunes.
La teoría dice:
Separa la interfaz de usuario de la lógica de negocios del acceso a datos
Pero la práctica se encarga de arruinarlo. Por ejemplo, si empezamos a hacer un sistema de contabilidad uno imagina inmediatamente los formularios de edición, los combos, las grillas (grids), etc… Entonces la mayoría hace la parte gráfica y luego va armando el servidor en base a ella.
Mal hecho, chico. Ahora el “servicio” depende de la parte gráfica (asi sea conceptualmente), y luego no portará bien a otro tipo de cliente (como un cliente web o uno celular). Ahora bien, lo más probable es que la cosa no sea tan extrema como para soportar celulares, el construir a base de la GUI genera un monton de problemas de diseño, y le quita flexibilidad.
Para poder separar el servidor del cliente, debemos PRECINDIR del cliente… o mejor dicho, de la representación gráfica del mismo. Una manera práctica es crear un “cliente” que sea la ventana de comandos de DOS (tipo Consola) o mucho mejor: Usar DUnit. Con DUnit, podemos hacer aplicaciones que hacen pruebas automatizadamente y a la vez, es un excelente cliente que nos permitira probar nuestro servidor sin amarrarlo a la interfaz gráfica.
Un asunto con la programación Cliente/Servidor es que la programación del Cliente es mucho más RAD pero la del servidor requiere más trabajo de código y no es tanto la parte de pegar componentes o controles.
Adicionalmente, al forzarnos a trabajar en código causa que mejoremos el diseño de la interfaze del servidor. Aunque parezca increible, muchas veces el tener que escribir el código y OBLIGAR a probarlo empieza a generar un efecto interesante: No me gusta escribir tanto código! Y como se vuelve un poco aburridor, obliga simplificar, reorganizar, reconstruir las clases hasta que hacen lo que tienen que hacer de la forma más práctica posible…
En la práctica, muchas veces se observa que de forma rutinaria en múltiples lugares se llama un proceso y se repiten varias líneas de código con ligeros cambios o parametros, el hacer un cliente con DUnit obliga a evadir ese código y a expresarlo de forma sencilla.Otra trampa común que se ve alentada por lo “simple” de generar un demo ejecutable en minutos es evadir las especificaciones, diseño y todo eso.
De paso, es la forma más segura de agregarle unos cuantos meses (o años) a un desarrollo de por cierto complicado, con más dolores de cabeza y más noches sin dormir. Asi, que mejor en este tipo de aplicaciones es hacer POR LO MENOS las especificaciones. Me gusta este artículo que da sugerencias muy prácticas y que de hecho estamos implementando en mi empresa El malabarista y se siente la mejora.
Pa’ afuera, no pa’ dentro
La mayoria de los programadores programa pa’dentro (empiezan por modelar los datos — como tablas y campos, vistas, etc… -) luego le meten el “alambre” que conecta a los datos y luego hacen los formularios. Luego las validaciones de entrada y por fin la lógica de negocios. Entonces quizás los reportes, el instalador, etc… ¿La razón? es que es MUY fácil hacerlo asi.
El problema es que pronto estará “hackeando” el código de lógica de negocios, para que se ADAPTE a los formularios, validaciones, campos, tablas, vistas y base de datos.
El punto es, el código de la base de datos, las tablas, los controles, etc… eso ya esta HECHO. Ya sea si usa Sql Server o Firebird o Paradox, el motor de base de datos ya sabe que hacer. Delphi tiene una excelente libreria, la VCL, y sabe que hacer. Lo UNICO que esta en DUDA es la lógica de la aplicación, el resto es carpinteria.
Programar pa’dentro es construir una casa asi: Se pavimenta la calle, se montan las paredes y el techo, se hace la parte de alambrado electrico y demás de las paredes, se pone los tomas de corriente, agua, gas, se cava hondo, se pone la tuberia interna, se cava mas, se ponen los cimientos. Ups! una roca estorbo la tuberia, toco cambiarla de puesto e interfiere con esa columna… rayos! eso desetabiliza el techo, reformemos el techo, No! el muro frontal hay que moverlo tan solo 1 centimetro!. Evidentemente, esta es una forma muy entretenidad de hacer casas. Y asi se entretienen la mayoria de los programadores, porque programa pa’dentro.
Es por eso que el orden lógico es: Lógica de negocios — Acceso a datos — Interface gráfica — Interface de Informes — Base de datos o sistema de almacenamiento — Todo lo demás.
O sea, como es una casa: Cimientos, tuberias, paredes, techo, pavimento. Pintura y acabado, perfecto!
El asunto es simple: El acceso a datos, la interface gráfica, los informes y la base de datos debe girar ALREDEDOR de la lógica de negocios y no al revez. Una vez que las clases y la funcionalidad interna estan estabilizadas, estas dictan de forma natural el diseño de la base de datos… incluso el acceso a datos se vera mucho más “limpio” y las consultas serán más simples. Conectar a la interface gráfica sera mucho más sencillo (en parte: La lógica de negocios tendra en si misma la mayor parte de las validaciones) y los informes seran más faciles de sacar (ya que la base de datos esta correctamente modelada a partir del modelo conceptual del programa!).
Va a sonar algo extraño que primero esta el “Acceso a datos” pero de ultimo esta “Base de datos” con mucho pasos intermedios. La razón? Es simple, el acceso a datos se deberia mantener en memoria!Esa es una de las grandes ventajas de usar pruebas automatizadas. Es MUY complejo armar una prueba automatizada sobre bases de datos reales (toca recrear la base de datos y llenar con datos de prueba para obtener pruebas repetibles!) y como al principio se va a hacer cambios importantes, no aguanta! asi que lo mas sencillo de hacer es modelar las clases de forma tal que puedan manejar datos en memoria.
Eso no significa necesariamente que hay que renunciar a los TDataSet. De hecho, no hay razon para hacerlo. Simplemente se pueden crear DataSet en memoria (con TClientDataSet), llenar los campos y datos de prueba, que normalmente son muy pocos.Eso es asi al menos al principio.
Obviamente al ir conectando las partes se llegara a un punto en donde el modelo de la base de datos se vera de forma evidente, y se injecta en el proyecto. Aqui metemos las pruebas de desempeño y simulación de cargas y demas cosas. El orden de desarrollo no es estrictamente sequencial, mas bien es un trabajo en paralelo. Evidentemente habra que hacer ajustes aqui y alla, pero si DEMORAMOS lo mas posible el meter todo lo que NO ES logica de negocios, el numero de cambios se reducira ampliamente.
Al programar pa’afuera, nos aseguramos de tener un cimiento solido sobre el cual construir. Eso en terminos de POO creara una alta cohesion y deberia bajar inter-dependencia (coupling) de las clases, que en términos generales es lo mejor.
Asi que recuerde: Programar pa’afuera (primero los cimientos, entonces lo demas) no solo hara a un sistema en cuanto a su codigo mas sano y solido, sino que tambien ayuda a un desarrollo más rápido y flexible!
