Estoy a punto de terminar la parte final (diseño y pruebas finales) y voy a ir posteando más información, asi que esten pendientes...
Etiquetas: paradondevamos, python
Sin embargo, django no soporta Sql Server, que es una base de datos muy usada por muchas empresas en Colombia, asi que estoy creandole el soporte para que django funcione con Sql Server.
Pueden ver los patch en http://code.djangoproject.com/ticket/5062.
Este es a la fecha el mayor aporte a un proyecto open source, aparte de los que he hecho a MUTIS y TodoAki.
P.D. Incluso me mencionaron el el weblog de django (para el observador cuidadoso, mamcx soy yo ;))
Etiquetas: django, python, Sql Server
Si, es un sueño trabajar en un juguete de esos ;).
Etiquetas: Sun
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.
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 "closed source" (o: "código cerrado") 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 "closed source" 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 ;)
Etiquetas: Open source, Software
Con gusto recibi en mi correo la invitación:
http://www.ittoolsltda.com/borland/correo_delphi/delphi1.htm
Espero ver a los paisas allí.
No falten!
Por eso, tengo un nuevo sitio: http://www.elmalabarista.com/.
Allí podrán encontrar el blog en http://www.elmalabarista.com/Blog.
Espero verlos a todos en el nuevo sitio ;)
El objetivo es armar un multi-lector de noticias que funcione por medio de plugins.
El grupo de usuarios es http://groups.google.com.co/group/todoaki/topics
Ademas, mejore la ubicacion y colores de los anuncios de google y amazon (que espero me permitan mantener este sitio) para que no sean tan intrusivos.
Ojala les gusten.
http://delphimedellin.blogspot.com/.
Etiquetas: Delphi, Grupos usuario
Estoy armando un grupo de usuarios.
Mas info:
http://www.clubdelphi.com/foros/showthread.php?p=160321#post160321
Etiquetas: Delphi, Grupos usuario
Programando al programador
Trata sobre lo que es minimamente necesario para trabajar de forma organizada.
Etiquetas: Mejorar como programador
Codificar para el cambio
http://bdn.borland.com/article/32388
Es algo que escribi hace dos años, cuando era mas joven pero igual de feo.
Espero les guste!
Etiquetas: Mejorar como programador
http://www.turboexplorer.com/
Estaran disponibles dentro de poco las TurboTools, en dos ediciones: Para necesidades básicas (gratuita, un solo lenguaje: Delphi nativo Win32, Delphi para .NET, C++, C#) y para profesionales (precio aún no firme pero sera <=US 500 para profesionales y <= US 100 para estudiantes).
Esto complementara las versiones superiores, que son más completas e integradas pero que represantaron una gran barrera de entrada para aquellos que no pueden costear un software de > US 1.000, y que ha hecho que muchos caigan en la pirateria y que otros ni siquiera hayan probado la mejor herramienta RAD jamas creada.
Faltan pocos días: Cuando este disponible, instalela, pruebela y compartala con sus amigos!
Etiquetas: Delphi
Llamando a los patriotas del open source, que tengan mucho tiempo libre, pocas aspiraciones economicas y un insano deseo de hacer algo relativamente cool
Cansados de falta de oportunidades de trabajo? Pues trabajo hay, y mucho. Para aquellos que no fueron aceptados en empresas cool como Google o Microsoft, seguro que la milicia es su ultima oportunidad.
Ahora si lo que quieres es un sueldo, mala suerte!
Es hora de presentarse al frente de batalla de las aplicaciones con sistemas avanzados de busqueda, clustering y procesamiento de idiomas. No aceptaremos la derrota ni permitiremos que Google sea el dueño de la fiesta . A menos que quieran sobornarnos con dinero, eso es...
La 3era unidad informatico-transportada de MUTIS necesita programadores valientes y comprometidos, dispuestos a hacer grandes sacrificios, dar su vida por el codigo. Si no estan dispuestos a dar su vida, aceptamos que nos den por lo menos unas cuantos horitas de su tiempo. Tambien nos rebajariamos por un sincero aplauso!
Nuestro batallon esta atascado en el puente de .NET, al este del oscuro valle de Endor, esperando poder movilizarse a las lucrativas tierras del Win32/64 y luego a los pastilzales libres del linux. Estamos a la espera de mejoras tecnologicas en el area del clustering y la metadata. Contamos contigo!
Con grandes motivaciones y un conjunto de normas eticas solidas e inamovibles, el comando superior de MUTIS (yo) esta dispuesto a guiarlos en esta ardua tarea. En caso de que nos les gusten mis normas, tambien tengo otras!
---------
No, en serio... ya me canse de tener a MUTIS (la -en el futuro- mejor libreria de indexacion y busqueda para Delphi) de amiga de las telarañas y ratones, y ya que logre terminar unos proyectos que me tenian al cuello, pienso seguirle trabajando.
Mas informacion sobre como alistarse en su centro de reclutamiento mas cercano:
http://www.solucionesvulcano.com/mutis/
Pueden bajarse el codigo fuente de:
https://svn.sourceforge.net/svnroot/mutis/trunk/Mutis
Usando subversion. Requiere Delphi 8+ para .NET
(Estoy ansioso de no depender exclusivamente de .NET, asi que si te interesa, alistate!)
Etiquetas: MUTIS, Open source
Por ejemplo... programar. Eso es sencillo!... si ya se que a muchas personas les parece que lo que tiene que ver con computadores es taaannn esoterico! es mágico! es de "genios"! Son nerds! Wooaaa!
Por ejemplo, la inteligencia artificial. Que es la inteligencia artificial?
Preguntale a un ser humano de verdad y veras que va a *suponer* que es que los computadores son inteligentes (imaginate!). Un ejemplo? A varios amigos mios les parece que el muñequito bailarin de Office (paperclip) es algo asi, al fin y al cabo, como supo que queria escribir una carta?
No pierdas tu tiempo buscando en Wikipedia o Google la respuesta, porque entonces no eres tan inteligente despues de todo...
La inteligencia artificial, realmente, es marketing nerd. Ya que los demás piensan que somos genios, pues demosle gusto. Asi que llamamos a nuestros programas inteligentes... que es tan falso que cuando afirmamos que nuestros programas son fáciles de usar y requieren poco o ningún entrenamiento o que son seguros, pero eso no se lo aseguro.
Lo que pasa es que el transeunte casual no sabe que Inteligencia Artificial no significa "Algo artificial, que es inteligente" sino "Algo que sabe o parece ARTIFICIALMENTE inteligente", o sea, como el jugo de naranja con sabor artificial que:
a) No sabe realmente a naranja
b) No se siente como una naranja
c) No huele como una naranja
d) No alimenta como una naranja
e) Si le hechas sal, no sabe tan rico como la naranja de verdad con sal
y lo más importante, no tiene pepitas de naranja. Es importante porque esas pepitas permiten a los más osados plantar su propio arbol de naranja y asi dejar de ir al supermercado.
Sin embargo, los jugos de sabor artificial son un exito comercial, a pesar que DEFINITIVAMENTE no se parecen a los sabores que afirman ser y no brindan los mismos beneficios. Igualmente, la IA es exitosa, asi sea en las peliculas, no importa que al fin de cuentas son solo formas ingeniosas de emplear matematicas avanzadas y uno que otro truco de magia aqui y alla.
Marketing nerd. Despues de todo, hay nerds que *si* saben de marketing. Increible!
Verdad que hablaba de la vida sencilla. Programar... eso es sencillo!
Por ejemplo, me pusieron hace unos años a hacer un sistema de contable que soporta los movimientos de entidades públicas (como alcaldia/municipios, contralorias y esas cosas). Me quedo bien. Funciona bien. Ahora, por ejemplo preguntenme cuanto se de contabilidad pública...
NADA.
Conclusión? Programar es tan sencillo que es posible hacer una cosa que mueve millones y millones de pesos sin tener idea de que es lo que teoricamente debe hacer.
Da miedo, verdad?
Lo que me lleva a que la vida debería de ser sencilla. Programar... eso es sencillo!
A proposito de la ignorancia mía con respecto a lo contable, no se como llevar un presupuesto... o si? No estoy seguro, pero mejor me aseguro y contrato alguien que lo haga. Estar pendiente de las cosas rutinarias de la vida como cuando hay que pagar impuestos (en serio, hay que pagarlos) es dificil... programar es sencillo!
De vuelta al jugo con sabor artificial... de naranja, por supuesto. Un supuesto que tengo es que la vida deberia ser sencilla y programar... eso es sencillo! Pero que va, al igual que con el jugo de naranja, solo es un sabor artificial. La vida no es tan sencilla. Y no soy un genio, aunque lo cree mi mama. De hecho, con excepción de este tema, siempre parece que soy más inteligente por lo que puedo escribir que cuando se me conoce de persona.
Es que yo tambien.. se de marketing de nerds ;) Que a proposito, es como los magos: Mira la bolita, mira la bolita.. pufff!!! desparecio (aplausos) (magico, dicen unos, manos rapidas dice el mago)
Marketing nerd, que era el punto que se me acaba de ocurrir de esta incoherencia, que a proposito, se suponia que escribiria sobre otra cosa ;)
Etiquetas: Pensando pa'dentro
Etiquetas: MUTIS, Open source
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 Soluciones Vulcano Ltda 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 demas. 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!
Etiquetas: Mejorar como programador
La mayor debilidad se encuentra en su fortaleza
Y eso en cierto de la programación RAD. Click.. click.. tap.. RUN! y !presto! una aplicación de base de datos completa con interfaz de usuario y edición de datos en minutos, gracias al poder de Delphi.
Click.. click.. tap.. RUN.. CRASH!!! es el resultado de programar una aplicación real al estilo de los tutoriales que muestran como se conectan los controles... como si realmente enseñaran arquitectura....
El diseño del acceso a datos es el MEJOR equilibrado que he visto en todas las herramientas de desarrollo que he manejado (Visual FoxPro, Visual basic (aqui ni habia un diseño), Java, .NET). Aunque cada herramienta/plataforma tiene puntos muy fuertes (por ejemplo, en .NET es más simple hacer un acceso a datos válido para un ambiente Web) la arquitectura de datos (el combo de TDatabase/TDataSource/TDataSet) permite:
- Una interfaz sencilla para navegar datos... Next, Prior, First, Last. Funciones de búsqueda simples como Locate y sofisticadas como Filter.
- Una forma simple de editar. Edit, Post, Add. Hermoso.
- Un enlace a los controles que no apesta, como en Visual Basic. Con buen desempeño, visual (incluso se ven los datos en tiempo de diseño) que se puede "desconectar" temporalmente para soportar algún proceso y que simplemente, es tan bueno que no hay que hacerle nada más.
- Lo más importante: En lo que respecta a los controles, solo entienden una clase abstracta (TDataSource) y se puede intercambiar entre diversas versiones de TDataSet que conectan con distintas tecnologias como BDE, ADO, ODBC, Acceso directo o bases de datos como Sql Server, Firebird, Oracle, Acces... Asi que al contrarior que en otras herramientas no hay que alterar la interfaz grafica ni hacerle ningún código especial cuando se cambia la tecnologia que accede a los datos (algo desagradablemente común)
Lo que la mayoria de nosotros no captamos es que la arquitectura de Delphi SEPARA el acceso a datos de la interfaz gráfica y de como se conectan AMBAS. Pero igual el uso/código que se ve normalmente NO explota esta característica. Un ejemplo es cuando alguien decide (MUY inteligenteme) dejar de usar Paradox y volcarse a una base de datos como Firebird. Ahora el caudal de cambios que toca hacerle al código es impresionante....
- Toca cambiar los TDatabase de BDE a Interbase/Firebird. Este es simple... pero...
- Toca cambiar todos los TDataSet. Mucha gente mete los TDataSet en los formularios/reportes lo que es MUY mala idea. Otros son un poco mas listos y usan los TDataModules para ello, PERO, igual pueden ser muchos.
- Al pasar de un acceso basado en tablas como en paradox a uno por Sql o al cambiar DIALECTOS de Sql (como el que usa Sql Server a uno que usa Oracle) toca alterar las consultas y eso esta POR TODAS partes con codigo que encadena texto aqui y alla. Caos total.
Tecnicas de acceso a datos: La forma sencilla
Cuando uno aprende a programar conoce una de las cosas mas simples, las constantes. El ejemplo tipico es el del numero PI, el cual es algo como 3,1416. Y se nos enseña que es mas lindo hacer un
const PI = 3.1416;Porque en fin, algun dia cambiara PI... no realmente porque asi es el código más claro.
Ahora bien, la mayoría de la gente mete a lo bestia SQL asi:
lcSql := 'SELECT Id FROM Clientes WHERE Id=' + QuoteStr(Id) + ' ORDER BY '+ CampoOrden;Y parnafernalia como esa, que esta regada aqui y alla, mezclada entro los eventos de validación de los controles, los reportes, funciones.. es como una invación marciana en una pelicula cuando el soldado a punto de morir grita !estan en todas partes! y si, este tipo de cosas tambien me asuntan.
Recuerdan las constantes? Por si acaso, el valor de PI puede cambiar pero en fin, las constantes hacen mas legible el código. Lo que propongo es muy simple: En vez de meter Sql a lo bestia, lo dejamos encerraito como buen cachorro que es en una lista de constantes, como:
unit SqlConstY ahora si, existe un UNICO lugar donde alterar las definiciones de los sql. Un nuevo campo? Se paso de una tabla a una vista? No hay problema... bueno al menos ahora es claro DONDE buscar.
interface
const
SqlListaClientesPorId = 'SELECT Id FROM Clientes WHERE Id=%s ORDER BY %s';
implementation
end.
Pero si toda esta carreta fuera para decir que la solución es usar constantes... no!!! porque ser programador implica más!
La verdad, ese asunto de meter SQL como constantes tiene un uso limitado. La mayoría de los sql son generados al vuelo y deben ser más flexibles... además igual no se ha solucionado el asunto de tener que cambiar de componentes de acceso a datos.
De vuelta al comienzo. Recuerdan las ventajas del modelo de acceso a datos de Delphi? Principalmente, TDataSet es una clase abstracta de la cual derivan las diversas implementaciones. Asi que mejorando un poco, la idea es
unit AccesoDatos
interface
type
TGeneradorSql = class(TObject)
public
function GetSelect(Tablas:String;Campos:String;Filtro:String;Orden:String=''):String
end;
type
TAccesoDatos = class(TObject)
FCon:TAdoConnection;
function Conectar:Boolean;
public
function ObtenerSql( lcSql : String ) : TDataSet;
function EjecutarSql( lcSql : String ) : Integer;
function ActualizarDatos ( DataSets:array of TDataSet);
implementation
function TAccesoDatos .Conectar:Boolean
begin
// Crear aqui la coneccion con la respectiva cadena de conexion...
end;
function TAccesoDatos .ObtenerSql( lcSql : String ) : TDataSet;
begin
// Llamar a Conectar. De esa manera se accese a los datos y Conectardetermina
//si se soporta el modo StateFull o StateLess
// Crear el respectivo TDataSet con los diferentes parametros. Ejecutar la consulta, y retornar
end;
function TAccesoDatos .EjecutarSql( lcSql : String ) : Integer;
begin
// Para comandos como INSERT, DELETE y UPDATE. Retornar el numero de registros afectados y automaticamente ejecutar en el contexto de una transaccion
end;
function TAccesoDatos .ActualizarDatos ( DataSets:array of TDataSet);
begin
// Dentro de una transaccion realizar los post a los TDataSet enviados.
end;
function TGeneradorSql .GetSelect(Tablas:String;Campos:String;Filtro:String;Orden:String=''):String
begin
// Hacer la concatenacion, como:
Result := 'SELECT '+ Campos + ' FROM ' + Tablas + ' WHERE '+ Filtro + ' ORDER BY '+ Orden
end;
end.
Obviamente, el código que pongo es solo para exponer la idea. Entremos a detallar:
1- Existe un UNICO lugar donde se administra el acceso a datos. Lo que implica un unico lugar donde cambiar los componentes. Por ejemplo, la conexion es un TAdoConection, solo pocos metodos lo tocan asi que hacer el cambio es cuestion de minutos
2- Metodos bien definidos para hacer selects, inserts, updates, que automatizan la logica de las transacciones, y virtualizan la creación de componentes permitiendo mayor reutilización y menor acople. Hacerle una llamado es muy simple, algo como
oDataSet := AccesoDatos.ObtenerSql(Sql_Clientes);
Noten que nada de tocar la conexión ni de crear objetos TAdo esto TDBE aquello....
3- Una clase que se encarga de hacer las concatenacions de las tablas, campos, filtros, orders, etc... Eso significa la posibilidad de adaptarse a los diferentes dialectos y MENOS errores por causa de concatenar mal las cosas. Entonces es mas simple:
lcSql := GeneradorSql.GetSelect("Clientes","Id","Id=1","Id")
y teneros la certeza que se devuelve la cadena SQL correcta. Y podemos expandir la idea para llamar procedimientos almacenados o INSERTS/UPDATE/DELETE.
La verdad, hacer este código no demora menos de 1 semana, incluyendo un parser más sofisticado de Sql... pero es una libreria reusable y de fácil mantenimiento. Incluso haciendo esto me di el lujo de hacer una interface orientada a objetos con código asi:
oSql.Tablas.Add("Clientes")Y se puede reversar, o sea, a partir de una cadena SQL se obtiene una defincion de las tablas, campos, filtros, etc...!!!
oSql.Campos.Add("Id","N")
oSql.Filtro.Add("Id=1")
oSql.Filtro.Add("Activo=1", AND)
lcSql := oSql.Sql;
Ahora, el asunto es que se deberia hacer subclases de acuedo a cada aplicacion. Piensen en algo como:
type
TAccesoDatosFacturacion = class(TAccesoDatos)
public
function ObtenerClientes(Filtro:String;Orden:String) : TDataSet;
function ActualizarFactura(DataSets:array of TDataSets)
end;
El asunto es mantener un unico lugar que se encarge de tocar la base de datos y sus tablas. Es increiblemente compacto el código resultante y es maravilloso la facilidad de uso que se logra y las ventajas de poder alterar el acceso a datos, no solo sin afectar la interface gráfica que Delphi se encarga de ello, sino sin alterar la LOGICA de nuestras aplicaciones!
Ahora bien, si quieren un producto más sofisticado, en Delphi 7 Architect/Delphi 2005 Architect
se encuentra Bold/ECO que es un paso mas arriba en este camino, en donde ahora los objetos se mapean a la estructura de la base de datos y existe una mayor facilidad y menos código. Esto se llama librerias de persistencia de objetos (Object Persistance Frameworks)
Otra alternativa es lo que la gente de RemObjects hace con DataAbstract, lo cual es una versión mucho más sofisiticada de la idea que presento aquí y que es ideal para un desarrollo más fuerte... darle una mirada tambien les puede ayudar a entender más el concepto!
Etiquetas: Mejorar como programador
Es dificil enseñarle nuevos trucos a un perro viejo, pero este es uno que vale la pena. En primer lugar, no hay que invertir dinero, se puede conseguir las herramientas de Unit Testing de forma gratuita. Con Delphi, se usa DUnit (el cual esta integrado dentro de Delphi 2005).
En la página de DUnit hay tutoriales sobre como se hace un test. En esencia? Es simplemente hacer una prueba de escritorio, pero en vez de escribir sobre el papel se escribe código real, el cual queda guardado para futuras pruebas. Tambien se puede ver como almacenar para la posteridad una sesión de depuracion...
Que ventajas aporta hacer Unit Testing? Estas son algunas que personalmente he observado:
- Enfoca el esfuerzo de desarrollo en hacer código sin errores (al menos sin los obvios). El punto central de hacer Test es que el esfuerzo se pone en mantener el código funcionando correctamente y en sostenerlo de forma estable en el tiempo. Sin hacer test automaticos, el esfuerzo se diluye entre hacer nueva funcionalidad (incluso aunque sea innecesario) y en posponer la resolución de los problemas.
- Mayor confianza en el código. Es un sintoma muy común el "temor" a tocar el código fuente, porque al efectuar un cambio, este puede tener efectos colaterales y dañar funcionalidad que estaba trabajando bien antes. El tener una suite de pruebas permite detectar a tiempo cualquier efecto colaterar y permite entrar con confianza a hacer cambios internos (como por ejemplo, arreglar un código que no se entiende muy bien y es díficil de mantener) con la seguridad de que el resultado final seguira siendo correcto
- Ayuda a hacer clases correctamente. Un mal endemico en el desarrollo de software es tener código "mezclado" que hace múltiples tareas entre lógica de negocios, interface de usuarios, acceso a base de datos y código de utilerias. Este tipo de código es una fuente segura de errores, dificil de mantener y entender y muy frágil, porque el cambio en una línea de código afecta a muchas más, porque todo esta mezclado. El punto es, es horrible testear código asi. Por lo tanto, en el esfuerzo de hacer código/clases fáciles de testear como efecto secundario se fuerza a separar las tareas y en hacer código más modular, y más facil testear = más facil de entender = más facil de mantener = código más solido
- Ayuda a mantener el trabajo dentro de las fechas limites. Una recomendación es hacer el código de prueba ANTES de hacer el código como tal. Eso suena muy raro... pero es de las mejores ideas que se pueden implementar...
Mi empresa esta colaborando en el proyecto MUTIS el cual es algo complejo... Incluye portar cierto código que esta en Java/C# a Delphi. Significa hacer pruebas de depuración en ambas plataformas, todo el tiempo. Hacer una engine de indexación no es sencillo, es similar a crear un motor de base de datos con el agravante que no tenemos el presupuesto de Oracle o Microsoft y no mucha experiencia antes de embarcarnos en esto. Sin embargo, el empleo riguroso de unit testing nos ha ayudado, en especial a mi, a mantener el desarrollo bajo los estimativos de tiempo y a ser mucho más productivo. Al crear los esqueletos de que pruebas hay que hacer, es como tener una lista de tareas que se marcan completas cuando el código pase correctamente las pruebas.
Por ejemplo, supongamos que hay que hacer un software de facturación. En este tipo de software, hay que hacer procesos como aumentar/disminuir el inventario, devolver compras, dividir los pagos en cuotas y cosas asi. Hacer las pruebas ANTES del código es simplemente hacer esto:
procedure TestAumentarInventario
begin
CheckTrue(False);
end;
procedure TestDisminuirInventario
begin
CheckTrue(False);
end;
procedure TestDevolverCompra
begin
CheckTrue(False);
end;
procedure TestDividirEnCuotas
begin
CheckTrue(False);
end;
Se usa CheckTrue(False); para marcar que aún no se ha realizado la prueba de esa funcionalidad. Asi, que ahora hay una lista de 4 tareas... a eso me refiero con mantener el enfoque! Ahora DUnit nos va a informar que nos faltan por completar 4 test, y nosostros entonces vamos a hacer que esos test pasen bien. Si adicionalmente llenamos en blanco el resto de la funcionalidad de nuestro software vamos a poder hacer estimativos reales sobre cuanto nos va a costar terminar el programa... y los programadores en vez de llegar al trabajo preguntandose ¿y que hago ahora? y mientras lo piensan se ponen a navegar por Internet, van a tener una lista de tareas por hacer, que les muestra su progreso y que los mantiene MOTIVADOS!
Asi que si no estan haciendo unit testing empiezen ya! Bajense DUnit y lean un poco sobre este tema y miren los tutoriales.
Etiquetas: Mejorar como programador
Me refiero a estos dos:
(compiler error): symbol is not linked in executable
y
[Fatal Error] F2084 Internal Error: ILLK14301
Especialmente este ya tiene una solucion... afortunadamente. Pero el primero aun no :( (todavia estoy en la fase de identificación).
Estos errores ocurren principalmente debido a definiciones de codigo poco comunes... lo cual me remite al hecho que MUTIS es un port de un proyecto hecho originalmente en Java/C# y cuando se importan ciertas cosas dentro de Delphi pueden ocurrir casos inesperados....
Como se pude lidiar con este tipo de problemas?. La unica forma real es:
- Copiar el proyecto con problemas con otro nombre
- ELIMINAR todos los units. TODOS.
- Ir agregando uno a uno. Parar hasta donde se pueda compilar aunque no se tengan todos los untis originales
- Ver si ocurre el error
- Si no ocurre ir agregando y ver en que punto ocurre
- Cuando vuelva a ocurrir, entonces ya se sabe por lo menos en que conjunto de units esta el problema. Ir revisando uno a uno.... y esperar que se arregle!
- Cuando quede listo, entonces reportar a Quality Central (Delphi 2005 tiene el cliente de Quality Central integrado en el menú tools) el hallazgo, junto al código de ejemplo y como se puede solucionar... de esa manera los ingenieros de Borland tendrán un caso reproducible que puedan solucionar y nosotros los usuarios una oportunidad de resolver estos problemas mientras tanto.
Lo que recuerda lo importante de tener una jerarquia de clases bien estructurada, porque si no se pueden separar las clases por tener dependencias muy fuertes este trabajo se vuelve MUY dificil. Afortunadamente, con buenas practicas de desarrollo y programación con MUTIS fue posible aislar facilmente y en poco tiempo las clases con problemas. Poco a poco se va "limpiando" el codigo hasta que quede otra vez bien!
Adicionalmente, contar con una herramienta de control de código fuente es muuuuy útil porque le ayuda a uno a hacer cambios sin miedos y poder despues hacer un diff (diferencia) del código para detectar los puntos de cambio.
Etiquetas: Pensando pa'dentro
Etiquetas: MUTIS, Open source
Como se puede ver, los diseñadores de Soluciones Vulcano me obsequiaron 10 minutos de su tiempo y me crearon un Logo provisional. Tambien puse un sitio completo con Faqs, Foros, Noticias y todas esas cosas importantes. Espero les guste.
Más adelante estare colocando el fruto de mis 2 meses de port..... espero sea pronto!
Etiquetas: MUTIS, Open source
http://blogs.borland.com/abauer/archive/2005/02/08/2597.aspx
Mi primer contacto con Delphi fue con la version Personal de Delphi 3... recuerdo que pude hacer el mismo programa que habia hecho antes en Visual FoxPro 3 (unos 6 meses) en solo 2 meses (y con mas caracteristicas).
Todavía tengo la caja, el CD y el libro original!
Etiquetas: Delphi
Este proyecto tiene como proposito inicial realizar un port (reescritura) en Delphi del aclamado proyecto de Apache LUCENE, el cual es un indexador y buscador de información. Es la clase de software que usan los motores de búsqueda como Google y Altavista y abre todo un abanico de posibilidades de innovación al momento de hacer software.
Audiencia
Este proyecto es para desarrolladores de software con habilidades en Delphi, .NET, Linux y otros. No es para usuarios finales.
Para que sirve, Kimosave
1- Busqueda de texto a velocidad de base de datos (no, MUCHO MAS!).
2- Buscadores (como Google)
3- Investigacion, Mineria de informacion, analisis dimensionales
4- Procesar informacion no estructurada, como archivos de texto, musica y videos
Porque es importante esto?
1- NO EXISTE NINGUN INDEXADOR OPEN SOURCE para Delphi. Zero, nada. Lo unico decente que existe es http://www.tamaracka.com/ (Rubicon). Aunque es MUUUYYY bueno, y es una solucion COMPLETA y me parece super bien y no me doleria pagarles, necesito es algo que me permita incrustrar la engine dentro de varios programas que estoy planeando y necesito hacer cosas locas como mineria de datos... y luego de pensarlo durante meses decidi mas bien montarme en esta vaca loca.
2- LOS INDEXADORES OPEN SOURCE EXISTENTES TIENEN NULO O LIMITADO SOPORTE PARA ESPAÑOL
Aunque mi idea es mantener 100% compatibilidad de API y capacidades con Lucene y DotLucene (para hacer comparativas, test, etc...) me interesa es avanzar el soporte a español. Es definitivo, pues soy Colombiano y me toca hablar spanish ok?. Soporte al dialecto de cada area, como Mexico, España, Ecuador, Argentina. Que los resultados realmente esten en armonia con nuestra forma de ver las cosas y no como las suponen quienes viven al norte...
3- ENSEÑA COMO HACER PROCESAMIENTO MASIVO DE DATOS. Poca gente sabe como leer un archivo de 1 GIGA con maximo desempeño, con una excelente API Orientada a objetos, de forma flexible e intercambiable. Aun si no interesa el indexador como tal, seguro que el ver como se hacen ciertas cosas les sera muy util.
4- HABRE AREAS DE CONOCIMIENTO DIFERENTES. Hasta hace un año, yo pensaba al igual que muchos, que procesamiento masivo de informacion, que Google, que buscadores, que leer archivos a nivle de muchos megas/gigas, que analisis de texto, que parsing, que indexar datos es programacion estratosferica, solo accesequible a gigantes como MS, Oracle o IBM.
Que solo manejar bases de datos lo unico posible. Pero eso NO es asi.
En este momento estoy en Alpha. Espero para terminar el mes tener compatibilidad API con la version1.4 y que el programa compile 100% sin errores ni warnings... tambien estoy armando test con DUNIT y ya hay 25 que pasan ok.
Por ahora, la meta #1 es que el port a Delphi.NET quede 100% bien, sin errores y funcionando. Posteriormente reorganizar las cosas para que compile a Win32 (primero) y a MONO (despues). Por lo tanto, la version 1 NO TENDRA ni mejoras ni adiciones ni nada (obviamente, me refiero al nucleo. Cualquier codigo relacionado que no toque el API interno sera bienvenido)
Si se le miden, HAGANMELO SABER! con un comentario en el blog o visiten la página de sourceforge (https://sourceforge.net/projects/mutis/).
Que se necesita ya?
1- Gente que sepa leer C# o Java. Que verifique la conversion que haya hecho y corriga... Se necesita Delphi 8/2005 con .NET
2- Gente que testee la implementacion.
Por ahora, nada mas.
Que no se puede esperar (por ahora)
1- Que funcione. Si desean algo hecho, usen Rubicon o DotLucene. Una vez se logre la version 1 obviamente dejara de existir esta limitante
2- Que arme un sitio como Google. Lucene es SOLO el indice+buscador. Es una libreria que NO SABE NADA de como se lee una pagina web o un archivo o una base de datos, Sin embargo da la flexibilidad 100% de acomodarse a las necesidades.
Etiquetas: MUTIS, Open source
Funciona muy bien, ya lo he probado!
Etiquetas: Delphi
Con los cambios en los requerimientos y expectativas a la hora de hacer un desarrollo, donde no se puede conformar con solamente hacer interfaces nativas, sino además todo tipo de servidores, utilidades, conexión con otros sistemas y demás; unido a la necesidad creciente de ambientes de desarrollo más productivos y que funcionen con las mejores prácticas de desarollo causan que nuestras herramientas de programación sean, de hecho, más capaces pero a la vez más pesadas cada día.
Cuando uno compara el rendimiento que un IDE como Delphi 3 daba hace unos años, contra Delphi 2005 o Visual Studio.NET, es notable la sensación de "lentitud" a veces solo es una percepción y otras es una baja notoria. Por eso, muchos programadores mantienen las versiones viejas o usan un editor de texto para hacer cambios rápidos al código y asi no cargar con el peso de las prestaciones de los entornos más avanzados.
Afortunadamente, Delphi es un entorno muy administrable; y se puede ajustar a las necesidades. Es como un rompecabezas, que permite agregar y quitar piezas gracias a un diseño modular que permite ajustar el IDE tal como se desea.
Comó, entonces, hacer para que nuestra herramienta sea más agil y que a la vez no cause que perdamos las características que nos ofrecen?. En parte, es entender que no todos necesitamos todas las características que nos ofrece el IDE... si solo hacemos programación de componentes o servidores, seguro que no requerimos un soporte muy avanzado para fabricar GUIs...
Hay varias cosas que podemos hacer para que nuestro IDE sea más rápido. Varias son sentido común y otras es por medio de cambios en las configuraciones, hacking puro... asi que por favor haganlo bajo su responsabilidad y no lo hagan en medio de una entrega importante a un cliente!
La típica:
Mas memoria, mejor procesador, un disco duro más rápido. Agregaria defragmentación continua del mismo. Una solución odiosa, además... y muchas veces innecesaria. De hecho, cuantas veces no se compra un equipo nuevo e igual se siente la misma lentitud? Es más bien saber como optimizar el rendimiento...
Optimizar Windows:
Por aquí empieza todo.. desactivar los servicios innecesarios (que además es una práctica recomendada de seguridad). Cuando instalo Windows XP, recuerdo que después de arrancar esta cargada como en 180 MB de RAM... una vez se desactivan los servicios no necesarios me queda como en 96 RAM o algo así.... y no solo eso, el procesador tendra mejor respuesta al estar menos cargado. Una guía muy buena (en inglés) sobre que hace cada servicio y si se puede desactivar o no esta aquí. Recuerden, hay que usar el sentido común, existen servicios que para el usuario típico se pueden desactivar pero no para el desarrollador.
Quitar los paquetes de componentes que no se necesiten.
Por ejemplo, alguna vez usan los componentes compatibles con Win 3.1? No? Entonces se pueden desactivar. Cada paquete agrega tiempo de carga a Delphi y aumenta la memoria. No se preocupen, cuando se desactiva un paquete no se desinstala y se puede configurar cada proyecto particular para que cargue el paquete.
Se hace por el menú Component/Install Packages. Una vez quitan los que normalmente no usan, hacer click en Default para que a partir de ese momento los nuevos proyectos no lo carguen.
Pueden desinstalar tambien los paquetes que definitivamente no usen....
Probar en ambientes aislados.
Es común que se esten probando nuevas líbrerías y herramientas tanto para Delphi como para otras cosas... causando que el sistema se vaya ralentizando con el tiempo y se llene de basura. Con Delphi hay un truco para probar nuevos componentes desde Windows 2000 en adelante y es iniciar con un usuario diferente... Delphi carga solo con los componentes por defecto, lo instalamos, lo probamos y cuando este aprobado, lo montamos sobre nuestro usuario. No es muy efectivo, pero ayuda un poco.
Lo ideal, es montar y probar en un equipo independiente, y asi no alterar nuestro entorno de trabajo, que debe ser estable y rápido. Pero como no todo el mundo puede tener un equipo para estas cosas, lo ideal es usar la tecnología de equipos virtuales... muy recomendado es la herramieta VMWare. De esa forma podemos probar tranquilos sin alterar nuestro entorno de trabajo para nada (ademas que va de lujo a la hora de probar las aplicaciones ;) )
Hacking Delphi 2005.
Hasta aquí, lo básico. Pero existe una guía para hackear Delphi 2005 y eliminar POR COMPLETO cualquier dependencia en .NET. Una vez hecho esto, se pueden pasar de tiempos de carga del IDE de 1-2 minutos a 20 seg. en un Pentium III con 256 RAM, la guía es esta.
Ahora bien, una vez más sentido común... puede que no a todos les convenga salir del .NET, por ejemplo en mi empresa hacemos desarrollos con ASP.NET y obviamente lo necesitamos, pero da unas buenas ideas en como mejorar el desempeño aún con el .NET instalado.
El truco se puede expandir si se sigue las técnicas de los arquitectos de Delphi 2005 que esta en este blog que aplica para Delphi 2005 y Delphi 8 y versiones anteriores...
La idea se basa en armar distintos perfiles en el registro y asi cargar solo lo necesario.
En resumen es cuestión de conocer la herramienta y ajustarla a las necesidades. Algo que no se puede desaprovechar, sabiendo que existen las maneras!
Cuando uno compara el rendimiento que un IDE como Delphi 3 daba hace unos años, contra Delphi 2005 o Visual Studio.NET, es notable la sensación de "lentitud" a veces solo es una percepción y otras es una baja notoria. Por eso, muchos programadores mantienen las versiones viejas o usan un editor de texto para hacer cambios rápidos al código y asi no cargar con el peso de las prestaciones de los entornos más avanzados.
Afortunadamente, Delphi es un entorno muy administrable; y se puede ajustar a las necesidades. Es como un rompecabezas, que permite agregar y quitar piezas gracias a un diseño modular que permite ajustar el IDE tal como se desea.
Comó, entonces, hacer para que nuestra herramienta sea más agil y que a la vez no cause que perdamos las características que nos ofrecen?. En parte, es entender que no todos necesitamos todas las características que nos ofrece el IDE... si solo hacemos programación de componentes o servidores, seguro que no requerimos un soporte muy avanzado para fabricar GUIs...
Hay varias cosas que podemos hacer para que nuestro IDE sea más rápido. Varias son sentido común y otras es por medio de cambios en las configuraciones, hacking puro... asi que por favor haganlo bajo su responsabilidad y no lo hagan en medio de una entrega importante a un cliente!
La típica:
Mas memoria, mejor procesador, un disco duro más rápido. Agregaria defragmentación continua del mismo. Una solución odiosa, además... y muchas veces innecesaria. De hecho, cuantas veces no se compra un equipo nuevo e igual se siente la misma lentitud? Es más bien saber como optimizar el rendimiento...
Optimizar Windows:
Por aquí empieza todo.. desactivar los servicios innecesarios (que además es una práctica recomendada de seguridad). Cuando instalo Windows XP, recuerdo que después de arrancar esta cargada como en 180 MB de RAM... una vez se desactivan los servicios no necesarios me queda como en 96 RAM o algo así.... y no solo eso, el procesador tendra mejor respuesta al estar menos cargado. Una guía muy buena (en inglés) sobre que hace cada servicio y si se puede desactivar o no esta aquí. Recuerden, hay que usar el sentido común, existen servicios que para el usuario típico se pueden desactivar pero no para el desarrollador.
Quitar los paquetes de componentes que no se necesiten.
Por ejemplo, alguna vez usan los componentes compatibles con Win 3.1? No? Entonces se pueden desactivar. Cada paquete agrega tiempo de carga a Delphi y aumenta la memoria. No se preocupen, cuando se desactiva un paquete no se desinstala y se puede configurar cada proyecto particular para que cargue el paquete.
Se hace por el menú Component/Install Packages. Una vez quitan los que normalmente no usan, hacer click en Default para que a partir de ese momento los nuevos proyectos no lo carguen.
Pueden desinstalar tambien los paquetes que definitivamente no usen....
Probar en ambientes aislados.
Es común que se esten probando nuevas líbrerías y herramientas tanto para Delphi como para otras cosas... causando que el sistema se vaya ralentizando con el tiempo y se llene de basura. Con Delphi hay un truco para probar nuevos componentes desde Windows 2000 en adelante y es iniciar con un usuario diferente... Delphi carga solo con los componentes por defecto, lo instalamos, lo probamos y cuando este aprobado, lo montamos sobre nuestro usuario. No es muy efectivo, pero ayuda un poco.
Lo ideal, es montar y probar en un equipo independiente, y asi no alterar nuestro entorno de trabajo, que debe ser estable y rápido. Pero como no todo el mundo puede tener un equipo para estas cosas, lo ideal es usar la tecnología de equipos virtuales... muy recomendado es la herramieta VMWare. De esa forma podemos probar tranquilos sin alterar nuestro entorno de trabajo para nada (ademas que va de lujo a la hora de probar las aplicaciones ;) )
Hacking Delphi 2005.
Hasta aquí, lo básico. Pero existe una guía para hackear Delphi 2005 y eliminar POR COMPLETO cualquier dependencia en .NET. Una vez hecho esto, se pueden pasar de tiempos de carga del IDE de 1-2 minutos a 20 seg. en un Pentium III con 256 RAM, la guía es esta.
Ahora bien, una vez más sentido común... puede que no a todos les convenga salir del .NET, por ejemplo en mi empresa hacemos desarrollos con ASP.NET y obviamente lo necesitamos, pero da unas buenas ideas en como mejorar el desempeño aún con el .NET instalado.
El truco se puede expandir si se sigue las técnicas de los arquitectos de Delphi 2005 que esta en este blog que aplica para Delphi 2005 y Delphi 8 y versiones anteriores...
La idea se basa en armar distintos perfiles en el registro y asi cargar solo lo necesario.
En resumen es cuestión de conocer la herramienta y ajustarla a las necesidades. Algo que no se puede desaprovechar, sabiendo que existen las maneras!
Etiquetas: Delphi
Etiquetas: Mejorar como programador
Además, hay mejoras importantes como:
- Refactoring: Poder hacer cambios al código de forma correcta y que estos se distribuyan a todo el proyecto (por ejemplo, al cambiar el nombre de una clase, Delphi 2005 la actualiza, tanto en el lenguaje Delphi como en C#)
- Unit testing: Crear test con DUnit o NUnit de forma integrada, que ayuda a crear mejor código
- Mejoras importantes al editor de código como la notificación automática de errores de sintaxis, similar a como lo hace JBuilder
- Mejoras al compilador con Function Inline, nuevas sintaxis como el For..Loop y otros
Espero con ansías poder echarle mano y hacer un analisis personal del mismo...
Etiquetas: Delphi
Afrontemoslo: .NET es el nuevo chico del barrio! Y probablemente la presión de usarlo sea fuerte. Sin embargo, a veces esa presión impide el uso apropiado. Como todo, .NET es una tecnologia y toda tecnologia (o herramienta) debe usarse para la situación y contexto apropiado.
Llevo unos 2-3 años usando .NET y actualmente estoy implementando un sitio Web que emula la GUI de un sistema ERP hecho en Windows. Definitivamente, se ha vuelto un mounstro el desarrollo, aunque en lineas generales estoy contento con el uso de ASP.NET. Ya he tocado casi toda areá importante del mismo y he sobrevivido a una actualización del mismo. También se intento portar una aplicación de nómina a .NET (y falló), asi que en base a mi experiencia y la acumulada por otros:
.NET: Fue una decisión inteligente si....
Llevo unos 2-3 años usando .NET y actualmente estoy implementando un sitio Web que emula la GUI de un sistema ERP hecho en Windows. Definitivamente, se ha vuelto un mounstro el desarrollo, aunque en lineas generales estoy contento con el uso de ASP.NET. Ya he tocado casi toda areá importante del mismo y he sobrevivido a una actualización del mismo. También se intento portar una aplicación de nómina a .NET (y falló), asi que en base a mi experiencia y la acumulada por otros:
.NET: Fue una decisión inteligente si....
- Se hacia una aplicación ASP.NET o un Servicio Web XML. Es un GRAN avance sobre ASP tradicional, aunque dependiendo del tipo de sitio o aplicación un avanze moderado o nulo sobre el uso de Delphi e IntraWeb o RemObjects para servicios Web
- La aplicación es para el servidor. El servidor es a) Un hosting externo b)Un sistema que puede ser actualizado (instalado otras cosas) y PREFERIBLEMENTE que tenga una persona competente soportando la red
- Estamos apuntando a un desarrollo que se liberará en el futuro (2-5 años)
- Tuvimos la desgracia de usar VB ;) (no en serio, ya estamos usando Delphi, no?)
- Desplegamos la aplicación en CD o no hay muchos despliegues
- El cliente tiene equipos de 1 Giga de procesador y mas de 256 ram
.NET: No es una buena decisión si....
- Para aplicaciones GUI nativas (que no son páginas web sino ventanas normales). Actualmente .NET es un retroceso en esta area y los componentes por defecto son MUY pobres. Es obligatorio adquirir componentes de terceros para aparentar las mismas capacidades esteticas y practicas de los nativos de Win32. Sin embargo, Delphi 8 tiene una versión para .NET de su VCL, asi que no es tan malo para nosotros.
- No hay control en la distribución. No se puede asegurar si el cliente a)Tiene el runtime de .NET b) Deseará/estará en capacidad de instalar el runtime Y CUALQUIER prerequisito adicional. .NET implica más costos de despliegue.
- La aplicación se descarga por Internet
- Soportar Win95 y Win98
- Debe tener buen desempeño en equipos con baja RAM. Este punto es importante. Normalmente si alguien apunta "debo soportar Win95 con 64 RAM" la respuesta es "Actualiza a WinXP y pon más RAM!" aunque tiene sentido, aún es normal encontrar equipos con WinXP y 128 de RAM (por ejemplo: pórtatiles) o tan cargados que la memoria disponible es poca. Seria poco justificable que una aplicación hecha en Win32 funciona bien bajo estas circunstancias y otra con .NET no. Si es el caso, el problema no es de la máquina NI del cliente: es un error al seleccionar la herramienta.
En resumen:
- Aplicaciones servidor .NET Ok
- Aplicaciones cliente Mejor Win32
Nunca es bueno olvidar que se trabajá al cliente y no al departamento de mercadeo de las empresas que producen plataformas.
Pero, y como estar preparados?
Es bueno estudiar .NET y jugar con él. La ventaja es que Delphi puede crear aplicaciones que se ejecutan nativamente sobre AMBAS plataformas lo que implica el mejor retorno a la inversión. Además, no olviden que Delphi 9 tendra integrado en el mismo IDE tanto el compilador para Win32 como el de .NET ;)
Pero, y como estar preparados?
Es bueno estudiar .NET y jugar con él. La ventaja es que Delphi puede crear aplicaciones que se ejecutan nativamente sobre AMBAS plataformas lo que implica el mejor retorno a la inversión. Además, no olviden que Delphi 9 tendra integrado en el mismo IDE tanto el compilador para Win32 como el de .NET ;)
Etiquetas: Mejorar como programador
Saber hacer compras es importante. Es casi inimaginable que alguien le pregunte a su vecino "Me haces la lista de compras?" porque obviamente los gustos varian o pueden haber consideraciones médicas o de otra indole que hacen que la comida de uno no sea la adecuada para otros. Definitivamente se aprecia cuando nos sugieren algo nuevo, pero al final termina uno decidiendo.
Sin embargo, con el desarrollo pasa algo diferente: Todo el mundo espera que los demás le digan que hacer y con que hacerlo, aunque al final (y repetidamente) nos cause "indigestión". El problema es un poco complicado porque la técnologia es complicada. Aunque se aprecien las recomendaciones, debemos saber hacer la "lista de compras". Para ello, es bueno hacer las siguientes preguntas, divididas entre los distintos componentes principales de una aplicación multi-nivel:
Base de datos
Dividamos en los grupos las bases de datos:
Sin embargo, con el desarrollo pasa algo diferente: Todo el mundo espera que los demás le digan que hacer y con que hacerlo, aunque al final (y repetidamente) nos cause "indigestión". El problema es un poco complicado porque la técnologia es complicada. Aunque se aprecien las recomendaciones, debemos saber hacer la "lista de compras". Para ello, es bueno hacer las siguientes preguntas, divididas entre los distintos componentes principales de una aplicación multi-nivel:
Base de datos
Dividamos en los grupos las bases de datos:
- Motores Sql
Son aquellas que tienen un componente servidor, se accesan por un protocolo de Red, y usan principalmente Sql (el lenguaje). Se instalan independientemente de la aplicación y se accesan comúnmente por más de una aplicación.
Ejemplos: Sql Server, MSDE, Oracle, Interbase/Firebird, MySql, Postgree, nexusDB.
Ejemplos: Sql Server, MSDE, Oracle, Interbase/Firebird, MySql, Postgree, nexusDB.
- Embeidas o incrustradas
Aquellas que tienen la capacidad de almacenar localmente datos, no requieren administración y estan intimamente ligadas a la aplicación y por lo general son útiles solo a ella.
Ejemplos: Firebird Embebed, NexusDB, MySql?, Acces, Paradox.
Tradicionalmente, la mayoría de los programadores de Delphi conocen por primera vez Paradox. Igualmente si vienen de programar en Visual Basic entonces Acces. Aunque esas bases de datos sean aceptables, para aplicaciones Multi-Nivel es mejor NO usarlas. Para elegir una base de datos se debe considerar:
Ejemplos: Firebird Embebed, NexusDB, MySql?, Acces, Paradox.
Tradicionalmente, la mayoría de los programadores de Delphi conocen por primera vez Paradox. Igualmente si vienen de programar en Visual Basic entonces Acces. Aunque esas bases de datos sean aceptables, para aplicaciones Multi-Nivel es mejor NO usarlas. Para elegir una base de datos se debe considerar:
- Mercado objetivo:
¿Nuestros posibles clientes ya invirtieron en una plataforma de base de datos, compraron o tienen Sql Server, Oracle, DB2, MySql, etc...? Igualmente ¿Cual plataforma estarían más dispuesto a aceptar? ¿Disponen de un administrador que se encarge de parchar, configurar, asegurar e integrar la base de datos, o es poco probable?
Digamos que el mercado se divide en "Empresarial" y "lo demás". Un mercado empresarial responde mejor si nos integramos con lo que ya tienen, lo cual implica el combo 3: Sql Server, Oracle, DB2. Si el cliente esta sobre Linux, lo más probable es que el combo sea MySql, Oracle, DB2 o Postgree.
Nos haremos un favor si aceptamos que el cliente ha adquirido una plataforma y esta deseoso de poder aprovecharla al máximo. Sin embargo en "lo demás" incluyamos todo caso en donde a)No hay quien administre la BD b)Se requiere una aplicación compacta, con costos muy bajos o nulos de administración c)Utilidades o aplicaciones que almacenan información pero que sobreviven por fuera del entorno empresarial o se integran por otros medios (por ejemplo, si hacemos una aplicación como un cliente de correo, es poco probable que justifique almacenar los correos en una BD empresarial)
Si hacemos una aplicación que puda ser desplegada en un hosting externo, recordemos que las opciones más obvias son Sql Server, Acces, MySql.
Digamos que el mercado se divide en "Empresarial" y "lo demás". Un mercado empresarial responde mejor si nos integramos con lo que ya tienen, lo cual implica el combo 3: Sql Server, Oracle, DB2. Si el cliente esta sobre Linux, lo más probable es que el combo sea MySql, Oracle, DB2 o Postgree.
Nos haremos un favor si aceptamos que el cliente ha adquirido una plataforma y esta deseoso de poder aprovecharla al máximo. Sin embargo en "lo demás" incluyamos todo caso en donde a)No hay quien administre la BD b)Se requiere una aplicación compacta, con costos muy bajos o nulos de administración c)Utilidades o aplicaciones que almacenan información pero que sobreviven por fuera del entorno empresarial o se integran por otros medios (por ejemplo, si hacemos una aplicación como un cliente de correo, es poco probable que justifique almacenar los correos en una BD empresarial)
Si hacemos una aplicación que puda ser desplegada en un hosting externo, recordemos que las opciones más obvias son Sql Server, Acces, MySql.
- Portabilidad, Administración
¿Necesitamos que funcione en varias plataformas (De Win95 a Win2003 o Windows/Linux?) ¿El cliente obtiene más valor si administra la BD o si no lo hace?
La segunda pregunta es MUY importante. Si un cliente PIDE algo como Sql Server lo más probable es que el mayor valor lo obtenga en administrar su BD, o reusar la plataforma (por ejemplo: otras aplicaciones que compro usan Sql Server). Sin embargo, si tenemos como clientes a Pequeñas y Medianas empresas, o usuarios finales, el mayor valor está en NO tener que preocuparse por la base de datos (lo máximo será hacer copias). En este caso, una base de datos embeida es mucho mejor.
La segunda pregunta es MUY importante. Si un cliente PIDE algo como Sql Server lo más probable es que el mayor valor lo obtenga en administrar su BD, o reusar la plataforma (por ejemplo: otras aplicaciones que compro usan Sql Server). Sin embargo, si tenemos como clientes a Pequeñas y Medianas empresas, o usuarios finales, el mayor valor está en NO tener que preocuparse por la base de datos (lo máximo será hacer copias). En este caso, una base de datos embeida es mucho mejor.
- Estabilidad, Seguridad
Una base de datos es algo serio. No importa si almacena tarjetas de crédito o simplimente la lista de amigos: a nadie le gusta que se corrompan o pierdan los datos. Es por eso que motores como Paradox o FoxPro (el viejo) no tienen caso: no son estables ni seguros. Acces casi cae en esta categoría pero el uso común que tiene puede obligar su uso. El punto es que una base de datos, sea cual sea el uso que se le de, debe ser estable o proveer minimamente acceso seguro por contraseñas. Todas las que menciono cumplen con estas características a mayor o menor grado.
Un punto meritorio es que una base de datos para un sistema multi-nivel recibirá una carga de trabajo característica: Multiples clientes o threads (hilos) enviarán constatemente peticiones de datos. Es por eso que una base de datos que sea un motor sql (sea o no embeido) es la elección mas sabia. Una base de datos de archivos como Acces, Paradox, FoxPro NO esta hecha para esa carga de trabajo.
Un punto meritorio es que una base de datos para un sistema multi-nivel recibirá una carga de trabajo característica: Multiples clientes o threads (hilos) enviarán constatemente peticiones de datos. Es por eso que una base de datos que sea un motor sql (sea o no embeido) es la elección mas sabia. Una base de datos de archivos como Acces, Paradox, FoxPro NO esta hecha para esa carga de trabajo.
- Precio
Aunque de último, también es importante. Como regla general, los clientes empresariales DESEAN un motor comercial, asi que está bien usar uno. Sin embargo, a un cliente "pequeño" o usuario final lo puede perturbar que le cobren adicional por tener un motor de datos (que porque no lo va a reusar ni integrar no tiene justificación para costar de más) y se espera que el productor del programa se encarge de esto. Una base de datos embeida o gratis (como Firebird que cumple ambas) sería mucha mejor elección. Sea cual sea, el fabricante debería de incluir cualquier costo de la plataforma de datos dentro del programa.
Comunicación
Básicamente tenemos a nuestra disposición como desarrolladores de Delphi (marco como incluido a aquellas cosas que podemos usar en Delphi sin adquirir nada más):
Comunicación
Básicamente tenemos a nuestra disposición como desarrolladores de Delphi (marco como incluido a aquellas cosas que podemos usar en Delphi sin adquirir nada más):
- DCOM/COM+ (incluido: Viene en Windows)
- TCP/IP, UDP, HTTP (incluido: Indy y disponible con otros)
- SOAP/Servicios Web (incluido y disponible con terceros)
- .NET Remoting (incluido Delphi 8)
- MsgConnect (producto de terceros)
- RemObjects (producto de terceros)
- Kbmw (producto de terceros)
- Asta (producto de terceros)
Y otros que no listo aquí por ser menos populares.
Estas preguntas nos ayudarán a enteder que sistema de comunicación usar:
Estas preguntas nos ayudarán a enteder que sistema de comunicación usar:
- Esfuerzo
Como en todo, existe programación de "bajo" nivel y de "alto" nivel. O como me gusta decir, de alto esfuerzo y de bajo esfuerzo ;)
Una aplicación multi-nivel TIENE que lidiar con algunos o todos de estos requerimientos:
Una aplicación multi-nivel TIENE que lidiar con algunos o todos de estos requerimientos:
- Seguridad: Autenticar usuarios? cifrar conexión? Usar certificados? Abierta al mundo, en internet o dentro de una intranet?
- Rendimiento: Comprimir datos? Respuesta en tiempo real? Debe permitir comunicación en las dos vias - del servidor al cliente tambien, como en un chat-?
- Empaquetado: En forma binaria? XML?
- Estabilidad: Debe tener balanceo de carga? Fail-over?
- Manejo de sesión: Donde se almacena la sesión del usuario?
- Compatibilidad/Interoperabilidad: Debe soportar múltiples plataformas?
- Despliegue: Requiere un administrador de red para poder ser usado? Pasará sin complicaciones a travez de un firewall? Requiere alterar la máquina del cliente con componentes adicionales?
Esto implica que la parte de la comunicación se puede complicar bastante. Esfuerzo implica que si nos bajamos mucho de nivel (por ejemplo, TCP/IP) tendremos que implementar más servicios que si elegimos, o compramos, una solución más adecuada. Despues de haber trabajado en por lo menos 3 desarrollos importantes de tipo multi-nivel no hay que subestimar los altos costos en tiempo y esfuerzo que demanda la parte de la comunicación. NO quiero decir que este mál usar TCP/IP, sino que el protocolo es solo UNA PARTE de la solución completa.
Si vamos a hacer aplicaciones tipo servidor y clientes tradicionales de Internet (como un servidor FTP), o de alto rendimiento entonces es probable que nos vamos por los protocolos básicos. De lo contrario si hacemos aplicaciones de negocios (como una contabilidad) es MUCHO mejor ir con un framework prediseñado (como DataSnap, RemObject o ASTA). Les garantizó: les ahorrará muchos dolores de cabeza.
Si vamos a hacer aplicaciones tipo servidor y clientes tradicionales de Internet (como un servidor FTP), o de alto rendimiento entonces es probable que nos vamos por los protocolos básicos. De lo contrario si hacemos aplicaciones de negocios (como una contabilidad) es MUCHO mejor ir con un framework prediseñado (como DataSnap, RemObject o ASTA). Les garantizó: les ahorrará muchos dolores de cabeza.
- Enfoque
El enfoque se refiere al tipo de comunicación que por lo general se usará en el sistema.
- Archivos (como un sistema FTP)
Lo clave aquí es poder hacer comunicación binaria, posiblemente asincronica. Un framework como MsgConnect, RemObject, los componentes de Indy o .NET remoting son candidatos.
- Peer-to-peer: mensajería tipo chat
Es fundamental la comunicación en tiempo real, con comunicación en dos vías: Indy, MsgConnect, RemObjects.
- Aplicaciones de negocios y bases de datos
Requieren el espectro completo de la comunicación (seguridad, rendimiento, empaquetado, interoperabilidad, etc...) lo que implica que es MALA idea irse muy bajo. Si nos vamos con indy o TCP/IP plano nos cargaremos un trabajo que requiere una serie de habilidades diferentes al manejo de bases de datos. Es mucho mejor irse con DataSnap, RemObjects (y tal vez junto a DataAbstract), ASTA, Kbmw. Este es el area de los frameworks completos, sin duda.
El enfoque tambien está en el "estilo" del API de comunicación. Asta y DataSnap es orientado a DataSets. RemObjects/COM+ es a objetos. MsgConnect/SOAP a mensajes. Indy comandos.
El enfoque tambien está en el "estilo" del API de comunicación. Asta y DataSnap es orientado a DataSets. RemObjects/COM+ es a objetos. MsgConnect/SOAP a mensajes. Indy comandos.
- Interoperabilidad, despliegue
Depende enormemente en el uso de los formatos de intercambio de datos y la manera de conectarse. El despliegue implica si el ambiente es intranet o extranet.
En estos casos, la clave es usar protocolos estandar: Http/Https, SOAP, XML. Lo cual reduce las opciones a servicios web.
NO es buena idea intentar forzar un formato propietario porque al final, nadie querrá conversar con nuestro sistema ;)
Sin embargo, el uso de XML y SOAP / Http significa perdida de rendimiento y capacidad (sencilla) de comunicación tiempo real y en dos vias (que es el dominio de TCP/IP y UDP). Si deseamos AMBAS cosas debemos buscar un producto hibrido (como RemObject, ASTA y .NET Remoting) que permite intercambiar libremente protocolos y formatos (por ejemplo, RemObject permite usar a la vez Binario y XML, Http y TCP/IP sin alterar el código).
El despliegue impacta que tan fácil es la administración. Usando http y Soap (sea formato binario o XML) tendremos los menores problemas por causa de Firewalls. Usar DCOM/COM+ requiere un esfuerzo de administración mayor, especialmente si nuestra aplicación se distribuye masivamente y a clientes inferiores a Windows 2000. Igualmente .NET remoting requiere el despliegue de los prerequisitos y el runtime .NET.
En estos casos, la clave es usar protocolos estandar: Http/Https, SOAP, XML. Lo cual reduce las opciones a servicios web.
NO es buena idea intentar forzar un formato propietario porque al final, nadie querrá conversar con nuestro sistema ;)
Sin embargo, el uso de XML y SOAP / Http significa perdida de rendimiento y capacidad (sencilla) de comunicación tiempo real y en dos vias (que es el dominio de TCP/IP y UDP). Si deseamos AMBAS cosas debemos buscar un producto hibrido (como RemObject, ASTA y .NET Remoting) que permite intercambiar libremente protocolos y formatos (por ejemplo, RemObject permite usar a la vez Binario y XML, Http y TCP/IP sin alterar el código).
El despliegue impacta que tan fácil es la administración. Usando http y Soap (sea formato binario o XML) tendremos los menores problemas por causa de Firewalls. Usar DCOM/COM+ requiere un esfuerzo de administración mayor, especialmente si nuestra aplicación se distribuye masivamente y a clientes inferiores a Windows 2000. Igualmente .NET remoting requiere el despliegue de los prerequisitos y el runtime .NET.
- Seguridad, Desempeño, Escalabilidad
Tradicionalmente, DCOM/COM+ tienen por defecto lo mejor de estos 3. El hecho que se integre con la seguridad de Windows y sea aceptado en el ambiente empresarial es un punto fuerte. Sus capacidades de desempeño son muy buenas, y es muy fácil de usar con Delphi. En un ambiente Intranet/Windows para clientes corporativos seria una buena opción. Por otro lado, RemObjects, Asta proveen capacidades equiparables. DataSnap, Indy, .NET remoting requiere más esfuerzo en esta area.
El combo Base de Datos/Librería de comunicación es el núcleo del éxito en una aplicación n-tier y significa la diferencia entre una aplicación exitosa y una que no cumple con las expectativas. Es bueno tomarse el tiempo de analizar las alternativas ANTES de comprometerse a una en particular, porque una vez realizado es practicamente seguro que hay que depender de ella, con todos los problemas y dificultades, no solo durante el desarrollo sino a travez de la vida de la aplicación (que puede ser años!).
Espero que estas consideraciones sean útiles. Para la próxima ahora si algo más practico!
El combo Base de Datos/Librería de comunicación es el núcleo del éxito en una aplicación n-tier y significa la diferencia entre una aplicación exitosa y una que no cumple con las expectativas. Es bueno tomarse el tiempo de analizar las alternativas ANTES de comprometerse a una en particular, porque una vez realizado es practicamente seguro que hay que depender de ella, con todos los problemas y dificultades, no solo durante el desarrollo sino a travez de la vida de la aplicación (que puede ser años!).
Espero que estas consideraciones sean útiles. Para la próxima ahora si algo más practico!
Etiquetas: Mejorar como programador
No voy a repetir la información que ya está disponible (como que es n-tier, ver aquí (inglés)) y la idea es enfocarse en los conceptos más que en las tecnologías como tales. Los artículos suponen un conocimiento suficiente de Delphi.... para darse una idea leer en las ayudas sobre MIDAS o DataSnap y/o SOAP (Servicios Web).
El plan a seguir:
- Una introducción general (este artículo) (Listo)
- Aplicaciones Multi-Nivel: Haciendo la Lista de compras: Consejos sobre elección de tecnologías y el porque de las elecciones (Listo)
- Aplicaciones Multi-Nivel: Un ejemplo práctico (diseño): Un diseño completo de un servicio que se puede implementar con CUALQUIER herramienta
- Aplicaciones Multi-Nivel: Un ejemplo práctico (implementación): Como implementar el ejemplo con RemObjects.
No... no es en la herramienta. No se soluciona con un buen framework como DataSnap (incluido en Delphi) o RemObjects... no se arregla conectando la base de datos a un equipo remoto (aunque funcione). El problema no es tecnología.... es de entendimiento o concepto.
Supongamos que estamos navegando en una tabla o consulta... algo como:
DatosClientes.Next;
La parte DIFICIL de captar es esta: cuando movimos el dataset de donde y hacia donde fueron los datos y acciones? Pues... en memoria... (hey, no me dijiste que era DIFICIL?).... Ok... pensar: Realmente como se hizo esto? Obviamente se envio una acción que mueve el registro, el cual va a la memoria, coje la memoria, la desempaqueta, la interpreta, etc... O sea, se hacen muchos pasos aqui.
El punto es, que al hacer aplicaciones n-tier NOS TOCA HACER CADA PASO a diferencia de una ejecución local, que Delphi se encarga de todo el trabajo, en una remota no es asi. Y cada paso es mucho más costoso en términos de tiempo, procesamient que cuando se ejecuta localmente.
Que compone una aplicacion n-tier?
- Un canal de comunicación
- Un protocolo de comunicación
- Una especificación de como se envia/recibe la información
- Componentes que empaquetan y desempaquetan los datos en cada puerta de comunicación
- Una interface de como es el servidor
La clave para hacer una aplicación n-tier es que entre el cliente y el servidor MEDIA un servicio de mensajeria: con las mismas características que la mensajería corriente con la que enviamos correos electrónicos. Si se entiende como funciona el correo electrónico ya tenemos la capacidad mental de entender como hacer n-tier.
Repito:
- Necesitamos un canal de comunicación
- Que es por medio de un protocolo (como TCP/IP o Http)
- Definimos como es el formato de nuestros "correos"
- Y los interpretamos a cada lado de la comunicación
Definir la interface del Servidor no es hacer un componente
Un error común es que al hacer la interface del servidor se cree que se está haciendo un componente o una función cualquiera. Por ejemplo:
function Logearse(Usuario:String;Clave:String):Integer;
se implementa igual tanto si es un programa local como uno remoto... entonces creimos que estabamos haciendo componentes o funciones y luego escribimos:
ClienteRemoto: Apunta a un servidor:
ClienteRemoto.First;
ClienteRemoto.Nombre:=....
ClienteRemoto.Fecha:=...
.
.
ClienteRemoto.Guardar;
Recordemos los pasos para llegar a ClienteRemoto.First:
Procesos locales
Encode(ClienteRemote.First) Definir el correo
Establecer comunicación... Recibir si se hizo
Usando Http.... autenticar canal?
Decode(Datos del cliente)
ClienteRemoto.First;
Esperar respuesta en el cliente
Recibir Respuesta Servidor
Decode(Respuesta Servidor)
Ejecución Local ClienteRemoto.First
Eso ocurre si se nos olvida que MEDIA entre nuestro cliente y servidor un sistema de correo o mensajería, que se agrava mientras mas lejana es la comunicación, mas pedidos de nuevos mensajes se hagan y más grandes sean eston. Si nos molesta esperar a que nuestro cliente de correo baje los emails para darnos cuenta la cantidad de basura que recibimos (y que igual toco procesar) nos damos a la idea de lo que DEBEMOS evitar !
Por lo tanto, nuestra definición de la interfaze del servidor debe ser amiga de los mensajes, que IMPIDA que los cliente tengan que hacer muchas solicitudes y que envie/reciba la información necesaria... algo como:
ClienteRemoto.Guardar(Nombre,Fecha....);
ya es mucho mejor...
En el proximo artículo mostrare nuestro "carro de compras" con componentes y herramientas recomendadas para hacer una aplicación de estas con Delphi.
Etiquetas: Mejorar como programador
Pero... que te pasa! Ser músico te daría fama, médico prestigio, banquero dinero o artista un gran ego... será que tal vez ni el ego ni la fama o prestigio, ni siquiere el dinero es la motivación?
Si, ya que cumpli con la advertencia:
Como llegar a ser un programador...
Supongamos que aún estás a tiempo de salvarte y solo tienes una vaga idea de lo que vas ha hacer... o sea, ninguna. Como empezar? algunas sugerencias:
- Ve a una tienda de libros, coje uno sobre programación. Te encantaría uno de Delphi pero uno sobre C++ o Java daría igual (ya que dan más dolor de cabeza el efecto es mejor!)... Si quieres algo fácil, uno de Delphi o quizas JavaScript o VBScript
- Busca en internet un tutorial sobre programación.
- Abre Word/Excel. Ve a herramientas/Macros/Editor de Visual Basic. Dale F1 y sigue un ejemplo
Para un tutorial sencillo en Delphi visite a http://www.marcocantu.com/ y haz click en Essential Pascal y Essential Delphi (ahí versión en español también). También en la Web del Programador (Cursos Delphi) habrán algunos. Igualmente, un tutorial de JavaScript va bien si te gusta la idea de programar para Internet y de paso aprender lo básico de todo lenguaje.
Saber computación, instalar programas y lanzar comandos por DOS, navegar por Internet y buscar con Google ante cualquier duda SIN preguntar antes, son cualidades esenciales. Si no te creen un tipo tremendo con los computadores sería mejor que invirtieras algo de tiempo aprendiendo estás cosas....
!Luego, obviamente, la cuestión es conque voy a programar! La herramienta, la herramienta! Ok, el plan estandár sería comprar Delphi, pero sabias que :
- Puedes hacer tus primeros pasos usando el Editor de Visual Basic incluido en Word/Excel? Pero NO TE LO RECOMIENDO. Que hago? Perdonenme por recomendar usar Basic...Pero igual, es un camino (el camino del lado oscuro, digo yo)
- Mejor, puedes usar Notepad y JavaScript. Crea archivos de texto con la extensión .js en Windows 2000 y superior y ya ta... Ok, no ta pero es la idea
- Pero, HEY! yo quiero Delphi! No tengo PLATA! Ok, aunque la opción de piratear es bien tentadora puedes optar por conseguir la version personal de Delphi, o
bajarte DelphiScript . Tiene todo lo básico de Delphi, es gratis, legal y pasarlo luego al Delphi no es complicado. - O bajarte de http://www.borland.com/Delphi una versión trial (o comprar el producto).
Siguiente paso: Mirarte las ayudas o tutoriales y trata de seguirlos. Si llegas a esta punto, lo siento: te atrapo el bicho de la programación!
Próximanente: Como llegar a ser un BUEN programador? Esten en sintonia...
Zapatero a tus zapatos
... un dicho tan popular que muchos simplemente ni le hacen caso. Es increible la cantidad de veces que un desarrollador (como yo) se pone a hacer cosas en las cuales no esta experimentado y que no son el "core" o núcleo del sistema por el cual le están pagando...
Y es que los clichés a pesar de serlo, son generalmente ciertos... Por eso, si el trabajo es hacer aplicaciones y NO componentes o plataformas, pues ahí les dejo mi lista de componentes/ líbrerias favoritas! (Hey, no se enojen si no puse una en especial...)
No se quiebren la cabeza señores y señoritas que otros gustosamente lo han hecho!
Y es que los clichés a pesar de serlo, son generalmente ciertos... Por eso, si el trabajo es hacer aplicaciones y NO componentes o plataformas, pues ahí les dejo mi lista de componentes/ líbrerias favoritas! (Hey, no se enojen si no puse una en especial...)
No se quiebren la cabeza señores y señoritas que otros gustosamente lo han hecho!
Bases de datos
¡No más paradox por favor!
Firebird (http://firebird.sourceforge.net/) Motor Sql completo. Open Source!
IBExpert (http://www.ibexpert.com/) Administrador gráfico para Interbase/Firebird. Versión personal gratis
Controles
TMS (http://www.tmssoftware.com/) Conjunto MUY completo de componentes. Es comercial pero la constancia como se actualizan es impresionante. Además los trial son nada problematicos y permiten "jugar" sin molestias.
DevExpress (http://www.devexpress.com/) Por mucho, el mejor componente de grid (o grilla como le dicen los de España) y un excelente sistema de menus. Comercial pero lo vale!
TurboPower Abbrevia (http://sourceforge.net/projects/tpabbrevia/) y TurboPower Orpheus (http://sourceforge.net/projects/tporpheus/) Una excelente opción open source!
Acceso Cliente/Servidor - Multinivel - SOA
¡No más paradox por favor!
Firebird (http://firebird.sourceforge.net/) Motor Sql completo. Open Source!
IBExpert (http://www.ibexpert.com/) Administrador gráfico para Interbase/Firebird. Versión personal gratis
Controles
TMS (http://www.tmssoftware.com/) Conjunto MUY completo de componentes. Es comercial pero la constancia como se actualizan es impresionante. Además los trial son nada problematicos y permiten "jugar" sin molestias.
DevExpress (http://www.devexpress.com/) Por mucho, el mejor componente de grid (o grilla como le dicen los de España) y un excelente sistema de menus. Comercial pero lo vale!
TurboPower Abbrevia (http://sourceforge.net/projects/tpabbrevia/) y TurboPower Orpheus (http://sourceforge.net/projects/tporpheus/) Una excelente opción open source!
RemObjects (http://www.remobjects.com) Por mucho, lo MEJOR DE LO MEJOR para hacer aplicaciones distribuidas sin los líos de COM+ o TCP/IP, con servicio Web, comunicación binaria y XML, seguridad y mucho más. Un sueño!
MsgConnect (http://msgconnect.com/) Similar al anterior pero de más bajo nivel... sin embargo también simple de usar y util para aplicaciones peer-to-peer y tipo MS Messenger!