Nuevo libro de Delphi de Marco Cantu

El nuevo libro de Marco Cantu ha sido liberado. Parece un libro excelente como todos los que ha escrito, aunque este esta dedicado 100% a actualizar nuestro conocimiento y dominio de Delphi hacia la versión 2007 con todas las novedades: Delphi 2007 Handbook.

Por lo pronto ya lo pedí. Por cierto que ahora el libro se vende a través de un novedoso servicio de impresión bajo demanda: El libro se imprime a medida que se compra, por lo tanto cuando no se hace una inversión exorbitante de entrada. Cualquiera que escriba algo o tenga algo escrito, que pueda ser vendido, se puede subir a este servicio llamada Lulu, se le pone precio y si se vende, pues que bien (claro que ayuda si es algo útil para alguien mas :P )

Cuando me llegue espero tener la oportunidad de escribir una reseña. Mucha suerte a Marco, aunque la verdad creo que no la necesita (El libro rompió toda expectativa de venta en sus primeros días)

Dinamic binding for properties in the VCL

There is something that I *REALLY* wish to have in RAD Studio that I think is a really nice idea from VS and could be taken even beyond: Dynamic binding of component's properties to any data source (XML, DB, INI files, Registry, Porperties from other components/controls, etc.)

This could be a major step for VCL, plus I guess that RTTI and maybe initialization code might be the core of this technology, so it's not far from there. Just think about it!

That is just the kind of ideas that I think should be part of RAD, don't you think?

Empresa RADical con Delphi

El concepto RAD de Delphi es sorprendente. Ningún concepto me he hecho sentir mas cómodo programando pequeñas y medianas aplicaciones poderosas que el Rapid Application Develompent. Es tan fácil como jugar con Lego pero aquí puedes aprender a crear tus propias piezas y extenderlas hasta donde quieras, tus propios componentes y controles, así de sencillo, toma lo mejor de la programación orientada a objetos y lo aplica de manera pragmática. Sorprendentemente increíble y poderoso.

Lo que me pregunto es porque no he escuchado más de arquitectura y diseño de las aplicaciones creadas con Delphi más allá del RAD. No escucho o leo que alguien este aplicando o encontrando patrones de diseño aplicados al RAD. Parece que todos tendemos a confiar en el concepto atrás de la VCL y seguirlo pensando que es suficiente. En lo particular a mi me ha hecho sentir desorientado cuando trato de ir aun mas allá, hacer aplicaciones genéricas por ejemplo.

Digamos que quiero ser aun más productivo y crear un administrador de estilos gráficos (temas) para las aplicaciones, o un marco de persistencia (un Mapeador Objeto-Relacional por ejemplo) que pueda reutilizar de manera genérica.

Yo sé, estamos hablando de Delphi, no de Java. En Java hay muy interesantes conceptos que hacen a veces palidecer a Delphi en otros rubros: hablo de esfuerzos comunitarios bien apoyados como Spring, Hibernate, SWT; hablo de arquitectura ( Write-once-Run-everywhere del que la CLX fue un esbozo) y de sus aplicaciones empresariales, con transacciones distribuidas u orientadas a servicios (SOA).

¿Que nos impide usarlos con Delphi? Nada. ¿Que nos impide aplicarlos y mejorar aun mas el concepto RAD? De hecho nada, solo la finta de que Delphi es solo para aplicaciones GUI cliente/servidor. ¿Quien dijo eso? No sé, y no importa.

Quiero ver más de eso, quiero usar Delphi en un sistema ENORME, crear componentes reutilizables del tamaño de una aplicación mediana, que me permitan con unas líneas de código o de manera declarativa (mediante XML por ejemplo), unir mis clases con la base de datos y no preocuparme más por saber si la BDE esta descontinuada, la dbExpress mejoro, necesito comprar MyDAC o Borland le cambio el nombre de los componentes ADO a dbGo. Quiero poder hacer de manera sencilla transacciones que abarquen varios procedimientos y una forma fácil y eficiente de mantener la aplicación, aplicar temas, cambiar por completo la vista de mi aplicación sin impactar el estilo grafico sin que esto implique real esfuerzo, MAYOR DESACOPLAMIENTO.

De hecho voy a hacer algunos experimentos con esto: Teoria de patrones de diseño con RAD, algún ORM 100% desacoplado de la tecnología de almacenamiento de datos tal vez, controles con vista 99% personalizable. Ya no estamos lejos (JediVCL, InstantObjects, repositorio de patrones del IDE, ECO, CLX) pero mi propuesta es esa: generar más conocimiento y practica, subirnos a la ola en lugar de intentar subirla y dejarla pasar, digamos Practica de Arquitectura y Diseño avanzado con Delphi.

Patrones del exito

Muchos programadores han escuchado acerca de ó aplican de manera diaria en su trabajo el concepto de Patrón: una solución refinada y adecuada a un tipo de problema específico y bien identificado. Incluso existen los anti-patrones: supuestas soluciones o comportamientos, tendencias y reacciones comunes a determinados problemas, que terminan siendo un desastre por razones comprobadas a lo largo de la historia de la programación.

Ahora imaginemos la misma filosofía del patrón (ir mas allá de la simple resolución del problema), pero aplicada AL MISMÍSIMO COMPORTAMIENTO DEL PROGRAMADOR: los problemas a los que nos enfrentamos de manera constante, nuestro desarrollo profesional y todo nuestro trabajo diario analizados desde la perspectiva de programadores exitosos, con más de veinte años de experiencia y que se mantienen más que vigentes a la fecha, los patrones de comportamiento de los usuarios, de los jefes, pero sobre todo del programador en sí, con tips, consejos y sobre todo soluciones inteligentes llenas de pragmatismo.

Eso es exactamente lo que Andrew Hunt y David Thomas publicaron en un libro por demás excelente, titulado El programador pragmático (de hecho The pragmatic programmer: from journeyman to master ya que por supuesto, hasta donde yo se no ha sido publicado en español).

A pesar de haber salido en el año de 1999 (hace como 30 años-web ;) no deja ni dejara pronto de ser vigente en lo absoluto, de hecho esta gente se adelanto un poco al tiempo así que al contrario, yo diría que es más vigente que nunca, después de todo, la ciencia avanzara pero los humanos seguimos siendo humanos.

Los mismos autores mantienen un sitio web de su compañía: www.pragmaticprogrammer.com que junto con el libro ha sido un enorme éxito al mantener la mente de muchos programadores fresca y abierta para su uso continuo.

No hay forma de explicar mas el libro y la idea más que leerlo detenidamente y con verdadero "Análisis Critico" (tip no. 9 del mismo libro), pero basta decir que ha inspirado a la generación de programadores que ahora son líderes en la industria e innovadores como Martin Fowler (Refactoring), Kent Beck (Extreme programming), Alistair Cockburn (Crystal Clear) y un montón mas.

Por cierto, de acuerdo a wikipedia:

...la palabra pragmatismo proviene del vocablo griego praxis que significa acción. Para los pragmatistas la verdad debe ser medida de acuerdo con el éxito que tenga en la práctica. En el pragmatismo no existe el conocer por conocer. Si algo no tiene un fin o uso determinado no hay razón para que tal cosa exista.

El programador pragmático, por lo tanto se podría definir, pero solo en parte, como aquel que hace lo que funciona para lograr que las cosas se hagan, que piensa lo que está haciendo y no trabaja en automático, y tiene la experiencia y el uso de la inteligencia a su servicio todo el tiempo, se adapta al cambio y se mantiene actualizado.

Guia de Steve Trefethen para ser un guru de Delphi

En su ultima semana como empleado de CodeGear despues de 15 años, donde mejoro la VCL (la libreria de componentes y controles de Delphi para win32), Steve Trefethen nos proporciona unas muy interesantes listas de topicos tipo "mantra para la vida" que casi todo programador de Delphi deberiamos considerar.

Hasta ahora ha publicado la lista para la VCL asi como para RTL y object Pascal. Vale la pena pegar la lista enfrente del escritorio.

Actualizacion al 28 de junio 2007: Dos listas, igual de excelentes, se han añadido, una para el use del IDE de Delphi y otra muy, muy interesante titulada Delphi Community. Esta ultima contiene varios vinculos realmente indispensables.

Nueva version del Gadget de Conexiones RDP

Existe una nueva version del gadget del SideBar de Windows Vista, ConexionesRDP. Agregué el soporte para conexiones en modo consola (permite conectar a la consola en lugar de una sesion comun de terminal server) ademas de algunos ajustes con la caja que muestra las conexiones. Otro ajuste es el soporte para sistemas en ingles en donde el tipo de archivo RDP no es "Conexion a escritorio remoto" sino "Remote desktop connection".

Muchas gracias a los comentarios y sugerencias de Hector Barranco.

Delphi: entre dos tierras

Desde tiempos inmemoriales (en tiempo informatico) el programar con Delphi ha sido un estandarte que muchos hemos portado con orgullo en todo el mundo, como una elección que tiene tres cuestiones principales, (1) una idea en principio inovadora y realmente funcional que muchos copiaron: el verdadero "Rapid Application Development", (2) el ir en contra de la corriente, de la masa que se deja arrastrar al lado oscuro del "monopolio perverso", y sentir que caminas por el lado correcto, el lado que conserva el viejo sentido de "La verdad os hara libres", mientras que, (3) no dejar de tener ganancias por eso, se sigue aprovechando el instinto de conservación, el seguir avanzando con paso firme hacia el mundo empresarial, es decir, sin que una de nuestras motivaciónes deje de ser el tener ganancias por nuestro desempeño profesional.

Ahora mismo, tengo la sensación de que ese ideal se ha desvirtuado por un exceso de expectativas, y que ahora ese concepto se muestra mas como un idea mediocre que como la opción del punto medio.

Pareciera que el mundo decidió abandonar el ideal y radicalizarse, tomar partido y volverse de algún bando: por un lado la corriente Open Source, que conjunta esfuerzos individuales en una gran concierto que genera soluciones para todos gustos tendientes a la innovación, y por otro lado, la corriente menos innovadora pero mucho mas disciplinada, motorizada por el capital de la empresa mas grande y fuerte mas que por el mismo desarrollador. De repente Delphi se ve ahogándose entre estas dos corrientes, pues su compañía (al menos su ex-compañia Borland) parece destinada a no aprovechar ni la fuerza de la masa, ni la masa de la fuerza.

En lo particular, pienso que CodeGear (la nueva compañia de Delphi, engendro renovado de Borland) debe radicalizar el concepto de Delphi, y atacar desde alguna trinchera, no puede quedarse a fuego cruzado, esperando tener éxito por su sola disposición hacia el desarrollador.

Gadget del sidebar de Windows vista para Conexiones RDP

Esa nueva onda de los gadgets (o widgets en Mac y X) me parece interesante en cuanto a la usabilidad del sistema. En Mac se ven impresionantes cuando se aparecen y desaparecen, y aunque en Windows Vista no es tan asi, pues parece que funcionan bien.

Lo que mas llama la atencion es que el API del Sidebar de Vista sea abierto y se siga el mismo concepto que los google gadgets. Por otro lado, particularmente tengo la necesidad de entrar a una cantidad de servidores de Terminal Services de Windows y tengo una serie de archivos .RDP (que usa y guarda el cliente de terminal services MSTSC.EXE) para cada una de las aproximadamente 60 conexiones. En windows XP hice una barra de herramientas en la barra de tareas, la saque de ahi y la empotre (dock) en la parte superior de la pantalla, de manera que cuando subia el cursor aparecian todas mis conexiones y con un click conectaba a la que necesitara.

Resulta que en Vista no puedes descolgar barras de herramientas desde la barra de tareas (o por lo menos no encontre como hacerlo), por lo que vi una oportunidad de justificar la invesitgacion sobre la creacion de gadgets del sidebar. Por lo menos hacer un gadget que me muestre mis conexiones RDP y pueda accesar a ellas como lo hacia con XP (que ironia). En fin, el resultado es este gadget de Conexiones RDP que pueden descargar del Windows Live Gallery.

Si le resulta util a alguien mas, me alegraria mucho algun comentario para mejorarlo. Ya existian algunos gadgets para manejar conexiones, pero ninguno usaba archivos RDP, la ventaja de usar archivos RDPs me parece que es clara: puedes configurar cuantas sean, con todos los parametros que el cliente MSTSC.EXE te permite, y no se pierde la configuracion de las conexiones al perder la instancia del Gadget. Ni siquiera la configuracion de la carpeta de las conexiones se pierde pues mejor use el registro para guardarla, en lugar de los settings efimeros del API del Sidebar.

Para los que les interese, en el mismo sitio de Windows Live Gallery existe una seccion con recursos para desarrollar tus gadgets. Particularmente les recomiendo la referencia del Sidebar en MSDN.

Usando Crystal Clear -parte 2- Las Propiedades

Las propiedades de una metodologia son su codigo genetico, lo que la distingue de otras y le da cuerpo. Las propiedades de Crystal Clear son guias que al seguirlas, nos ayudan a llevar nuestros proyectos a una zona segura.

Crystal Clear es un Metodologia de desarrollo de software creada por Alistair Cockburn

Primero, debo resaltar que Crystal Clear, es una metodologia que se centra en una forma de pensar flexible y una filosofia de SEGURIDAD-HABITABILIDAD-EFICIENCIA hecha para adaptarse y mejorar, iteracion tras iteracion.

Las propiedades de Crystal Clear son 7. Las primeras 3 son obligatorias si se quiere seguir la metodologia, las siguientes son muy importantes y sirven para llevar el proyecto aun mas adentro en la zona de seguridad.

Propiedad 1: Entregas Frecuentes
Entregar código ejecutable, probado y usable a los usuarios, por lo menos una vez cada tres meses, si es cada uno o dos meses, mejor.

Al hacer esto aseguramos que nuestro proyecto no se despegara mucho de lo que el cliente necesita realmente, pues cada entrega formal, resultara en correcciones a los malentendidos que surgen continuamente en el analisis del sistema.

Ademas, si nos interesa entregar algo util para nuestros clientes -un software que realmente le genere valor- de esta manera le damos la oportunidad al usuario a que critique nuestra interfaz de usuario y el funcionamiento general del sistema antes de que continuemos creando mas codigo que podria terminar en la basura cuando nos digan "Esto no es lo que yo pedi."

Propiedad 2:Mejora reflexiva
Reunido por lo menos una vez en cada tres meses, durante media hora, una hora o medio día, para comparar notas, reflexionar, discutir nuestros hábitos de trabajo, y descubrir lo que nos acelera y lo que nos detiene y lo que podríamos mejorar.

Eso se llama hacer un "Taller de reflexion", obteniendo una lista de practicas o habitos de desarrollo que nos gustaria mantener, una lista de lo que nos gustaria intentar, y probablemente, una lista de lo que queremos evitar, todo esto escrito y publicado de alguna manera, a la vista de todos.

Esto nos genera una mejora continua en nuestro proyecto y nos da el tiempo para corregir el camino, acelerar el desarrollo y mejorar nuestros habitos y conocimiento de desarrollo.

Propiedad 3:Comunicación osmótica
La colocacion fisica del equipo de desarrollo es de lo mas importante, y la comunicacion osmotica se refiere a llevar la comunicacion al maximo nivel: Nos debe tomar menos de 30 segundos llevar nuestras dudas a los ojos u oídos de quien puede resolvérnoslas, debemos sentarnos en el mismo cuarto o en cubiculos contiguos. Captar algo relevante de la conversación entre otros miembros del equipo al menos cada pocos días.

El hecho de tener que levantarnos de nuestro escritorio, cruzar el pasillo y abrir una puerta, con toda seguridad nos distrae de nuestro tren de pensamiento. Irrumpir en la oficina de otro miembro del equipo y hacerle preguntas, a si sean de lo mas simple, terminara por retrasar bajar nuestra productividad de manera critica.

Comparado con hacer una pregunta a una persona que esta constantemente conectada en nuestro mismo tren de ideas, nos da la diferencia entre comunicacion cerrada y la mejor, comunicacion osmotica.

Propiedad 4: Seguridad personal

¿Podemos confesar a los demás que equivocamos nuestras estimaciones por mas del 50% o que hemos recibido una tentadora oferta de trabajo? ¿Podemos expresar nuestro desacuerdo con cualquiera respecto a la agenda en una reunión del equipo? ¿Podemos terminar largos debates sobre los diseños de otro miembro con un desacuerdo amistoso?

Fomentar la confianza y el respeto entre el entre el equipo, de manera que todos tengan claro que lo importante es lograr los objetivos del proyecto de manera conjunta. Asi, las equivocaciones e incapacidades de unos, pueden ser cubiertas por los demas, los miembros no temen exponerse, y el equipo respeta estas exposiciones.

Tres exposiciones en particular son importantes

• Revelar nuestra ignorancia
• Revelar nuestros errores
• Revelar nuestra incapacidad en una tarea asignada

Propiedad 5: Enfoque

Cada quien debe saber cuáles son los dos elementos de mas alta prioridad sobre los cuales trabaja en todo momento. Ademas, deberiamos tener garantizado todos por lo menos dos días seguidos y dos horas ininterrumpidas por día para trabajar en un proyecto.

Esto tiene una base demostrada y fundada en lo siguiente:

• Nuestro trabajo exige una alta concentracion en lo que hacemos para evitar errores y producir mas.
• Un problema que se puede resolver en un minuto de concentracion, nos puede llevar una hora o mas de manera dispersa.
• Una distraccion media, que nos hace llevar nuestro pensamiento a otro lugar, puede llevarnos a perder de diez a quince minutos de productividad.
• El "switchearnos" de un proyecto a otro nos lleva al menos entre una y dos horas.
• Despues de que un desarrollador esta sometido a constantes distracciones, el desgaste de energia mental termina por hacer que el desarrollador prefiera hacer cosas vanas (como chatear o navegar) entre una distraccion y otra. Lo mismo tiende a pasar con desarrolladores involucrados en tres proyectos o mas.

Propiedad 6: Acceso fácil a usuarios expertosNos deberia de tomar menos de tres días en promedio, desde que surge una duda respecto al uso del sistema, hasta que un usuario experto la resuelve. Inclusive lo deseable, es poder obtener las respuestas en unas cuantas horas cuando mucho.

Si surge una duda sobre en el desarrollo de la funcionalidad, y podemos levantar el telefono para comunicarnos con el usuario experto en el dominio, hacerle algunas preguntas y seguir con el desarrollo, entonces estamos del otro lado. Esto no es siempre posible, pero por lo menos sera importante poder agendar una cita para visitar o ser visitado por nuestro usuario experto.

Propiedad 7: Ambiente de desarrollo con Pruebas automáticas, Administracion de la configuración e integracion frecuente.

Poder dejar corriendo las pruebas de nuestro desarrollo hasta el final sin estar físicamente presente nos ahorra el tiempo que no tenemos, sin mencionar las ventajas de depuracion inmediata y de probar el codigo indiscriminadamente.

Todos los desarrolladores deberian ingresar el codigo en el que trabajan en un sistema de administracion de la configuración, de manera que este se encarge de llevar el control de versiones, documentos, etc. y escribir una nota útil sobre el código cuando lo ingresan.

El sistema se deberia integrar por lo menos dos veces a la semana, juntando el codigo de todos, compilandolo, y haciendolo pasar por todas las pruebas automaticas posibles, y obteniendo de esta manera codigo ejecutable constantemente.

El sistema funciona mas o menos asi: Se diseñan los test antes del desarrollo. El sistema se integra frecuentemente en el sistema de manejo de configuracion (ejemplo CVS) y se pasa por todos los test, mostrando los resultados de inmediato.

En los siguientes articulo sobre Crystal Clear expondre algunas tecnicas y estrategias sugeridas que nos ayudaran a lograr estas propiedades y las refuerzan.

Usando Crystal Clear en la PyMe de software (Introduccion)

Mejorar nuestras metodologias de desarrollo puede ser el paso mas firme que podemos dar como equipos de desarrollo de software.

Muchos programadores estamos aun acostumbrados a usar un metodo de desarrollo en Cascada (analizar todo el sistema > diseñar todo el sistema > programar todo el sistema -> depurar etc.) o peor aun: nos exponen el problema, y mal nos lo terminan de explicar, ya tiramos unas lineas de codigo -al menos mentalmente-, o tomamos la primer idea que parece cuadrar con el problema como si fuera la iluminacion venida de nuestra propia mente sobreestimada.

Esa "metodologia" se ha ido dejado atras en las potencias en desarrollo de software (India, Alemania, Japon, EUA, etc) desde hace bastante tiempo, incluso en algunos casos desde los 70's u 80's. No esperemos encontrar en estos tiempos una empresa de desarrollo de software de nivel internacional que use esta forma de hacer las cosas, pues es considerada una mala practica que lleva a un software inutil, retrasos exorbitantes, y disgusto en el cliente (sistemas de pesima calidad).

Por otro lado, precisamente a raiz de que los clientes -que antes muy probablemente no tenian una idea clara de lo que esperaban de un sistema- ahora comienzan a saber exigir calidad y saben con mucha mayor precision lo que un sistema puede hacer por ellos. Tambien esperan mucho mas profesionalismo ya que, con todo y pena debo mencionar, historicamente los agentes libres y las PyMEs de informatica en Latinoamerica se han portado como estrellas de rock cuando se trata de servicio al cliente.

Esperando sinceramente -y creyendo- que esos tiempos estan quedando atras, debemos buscar un metodologia que llene nuestras espectativas y con nos guste trabajar (habitabilidad), que nos ayude a asegurar que el software que desarrollamos llena las expectativas de nuestros clientes (seguridad), y nos permita trabajar en equipo una y otra vez, refinando con cada proyecto nuestras practicas y conocimiento (eficiencia).

Personalmente mi recomendacion es Crystal Clear, una metodologia agil muy flexible creada por Alistair Cockburn, que tiene precisamente estos tres conceptos como principios de la metodologia

• HABITABILIDAD
• EFICIENCIA
• SEGURIDAD PARA EL PROYECTO

La metodologia esta basada en ver al desarrollo de software como:

un juego economico de cooperacion, basado en objetivos, buscando un equilibrio entre la ambicion (terminar el proyecto pronto) y la inversion(actividades pensando en el futuro).

Explicando brevemente, por "un juego economico de cooperacion" se refiere a que es una actividad con reglas establecidas, que se practica en equipo y con el objetivo economico, un negocio. Se basa en realizar objetivos claros en los que cada en decision se determina un equilibrio entre terminar el software lo mas pronto posible (usar menos recursos) y las realizar las actividades que ayudaran a asegurar, mantener y posiblemente crecer en un futuro el sistema (invertir para el futuro).

En el siguiente articulo, expondre las Propiedades particulares de esta metodologia, que es la escencia del trabajo diario con ella.