GLGDW 2006
Inicio

Viernes 21

Sab 22 Mañana

Sab 22 Tarde

Dom 23 Mañana

Dom 23 Tarde

Lunes 24

Galerías

 

... a Conferencias

 
Anuncios




 
© PortalFox

GLGDW 2006

Resumen del Domingo 23 de Abril - Mañana

PorAmby


Hoy la llovizna era más fuerte en la mañana, la temperatura exterior más baja; pero el ambiente festivo de la conferencia se mantuvo bien alto.

Hoy vimos las Mejores prácticas en Refactoring, además vimos las mejores técnicas para creación de informes, la administrador de proyectos, creación de aplicaciones con arquitectura vertical y depuración. Pues tal y como pasó ayer, las expectativas eran altas y han sido cumplidas con creces.

Intentaré contarles un poco de lo que hemos visto, quizás no sea mucho, el cansancio se va notando, el esfuerzo de estar todo el tiempo con el idioma inglés, al paso de los días va pasando factura.

Pues bien, vamos allá con entusiasmo que hemos disfrutado de una excelente jornada.

Comenzó Nancy Folsom hablando de las Mejores técnicas sobre Refactoring (Best Practices for Error Handling). ¿Cómo se dirá en español? ¿Re-codificar? He buscado en varios diccionarios on-line y no aparece traducido, así que lo dejaré como Refactoring. ¿Qué es refactoring? Pues es la técnica que consiste en re escribir un código que por varias razones ha quedado mal, aunque funciona.

Este trabajo se basa en que la aplicación funciona, sin errores y de lo que se trata es de optimizar, mejorar la velocidad de respuesta, hacer más legible, facilitar la escalabilidad en el futuro, en fin, como dice la expresión, quitar todo lo que "huele mal" y no requiera gran inversión ya que el usuario seguramente no se enterará del cambio. Huele mal todo aquel código que sea incomprensible y que al intentar leer y trabajar sobre el, sea necesario detenerse a investigar a qué se refiere.

Hay que diferenciar entre lo que significa una buena práctica y el estilo personal de cada uno. En esta conferencia se trata de las mejores prácticas desde la perspectiva del ponente, lo cual no es en todos los casos, la misma que algunos de los presentes. Peor el objetivo del intercambio está asegurado y de la experiencia de cada uno, se obtienen muchas "mejores prácticas" a seguir.

No debemos confundir con la depuración ni con la incorporación de nuevas posibilidades a la aplicación a nivel de usuario, se trata de la corrección de malas técnicas de programación, por ejemplo:

  • Comentar lo que no se "autocomente" por los nombres de comandos o funciones (nativas o de usuario), comentar todo lo que responda a la pregunta ¿Por qué? ¿Por qué es necesario hacer esta acción en este momento?
  • Emplear el comando ASSERT, con determinada condición. Es muy aconsejable, porque en tiempo de ejecución si se emplea el analizador de trayecto, habrá información en este comando y los comentarios definitivamente no dejan rastro.

Aunque, es a gusto del consumidor, por ejemplo Doug Hennig defiende el uso de comentarios, incluso tiene la costumbre de poner tras cada ENDDIF, ENDDO, ENDFOR la condición de inicio del bloque para identificar rápidamente donde comienza.

  • La clave del refactoring es hacer sólo un cambio a la vez y probarlo, porque estamos partiendo de un código que trabaja bien.
  • En lugares como el MESSAGEBOX(), emplear constantes con nombres que contengan un significado en lugar de los valores que trae la función. Por ejemplo, si tenemos en una constante MessageAbortRetryIgnore, inmediatamente veremos de qué tipo de mensaje estamos hablando.
  • No escribir código en el bloque THEN y ELSE de un comando IF, sino enviar ese código a un método, para garantizar la mantenibilidad y redibilidad de código con varios bloques IF-ELSE-ENDDIF anidados.
  • Al notar que existe algún otro aspecto sensible de refactorizar, no comenzarlo teniendo un tema a la mitad. Poner algún comentario y dejar para otro momento, el comentario debe ser identificativo, algo como "Pendiente", "PorHacer...", algo por lo que podamos luego hacer una búsqueda y nos lleve a estos puntos. Para estos comentarios, lo mejor es emplear código almacenado en la tabla FoxCode que controla IntelliSense.
  • Evitar al máximo la evaluación de condiciones negativas, es decir, es preferible IF condición a IF !condición

Definitivamente ha sido gran idea el formato de esta Conferencia, hablaré con Whil Hentzen para agradecerle, porque el intercambio resulta extremadamente útil. Lo único malo, es que me cuesta mucho comentarlo a ustedes en este reporte porque es un bombardeo constante de ideas complejo de reproducir. Las sesiones no están siendo grabadas.

Por cierto, y no tiene nada que ver con la ponencia como tal, Nancy mostró un uso muy interesante de la Herramienta ToolBox que vino con VFP 8.0. Creó sus propios paneles según el tópico a mostrar y preparó en código script sus ejemplos, estuvo muy fácil de leer y ubicar.

Disfruté mucho con esta presentación. Gracias Nancy !!

Tuvimos un pequeño receso, no dejé para luego mis felicitaciones al organizador del evento. Whil Hentzen confesó que él mismo tuvo sus dudas sobre la efectividad real de emplear este formato; pero que le complace mucho porque ha recibido muy buenas opiniones. Aproveché para preguntar si tenía pensado algún libro con un resumen de esta conferencia y está en los planes, ¡¡ Bien !! Pudiera ser muy útil. Y ya puestos a pedir ... ¿por qué no publicar en español? Bueno, tienen alguna experiencia en este sentido con países europeos como Alemania y Francia, así que no tenemos todo perdido, es más, acordamos abordar el tema después de la Conferencia... a ver si logramos hacer algo bueno en este sentido.

También hablé con Tamar y en efecto, la idea de escribir sobre la interfaz de usuario, especialmente a partir de los malos ejemplos, le atrae mucho; pero no hay tiempo en el futuro próximo para hacerlo.

Café en mano, tocó el turno de escuchar a Barbara Peisch, quien es autora de numerosos artículos técnicos en las revistas más importantes de VFP, es ponente en algunas Conferencias y encuentros de los grupos de usuarios y le avala la experiencia de desarrollar aplicación desde hace casi 20 años. Barbara contó sobre las Mejores prácticas de trabajo con Informes (Best Practices for Reporting and Output).

En realidad la charla no tuvo nada que ver con lo que yo esperaba. Seguramente porque yo esperaba la charla que podía haber sido en otro tipo de Conferencia, no en esta, que tiene un formato tan original. Barbara apenas tocó con pinceladas aspectos relativos a las Novedades de VFP 9.0 relativas a Informes; pero ese, sin dudas no era su objetivo. Su objetivo fue mostrar una clase en que que controla todo proceso previo al lanzamiento de un informe, la selección de los datos a mostrar, tipo de salida del informe, tipo de comportamiento (REPORTBEHAVIOR 80 ó 90). Y aunque fue un poco engorroso al inicio entender su proceder; pero luego, cuando necesitó agregar un informe a su clase esto demoró un tiempo mínimo, apenas el necesario para configurar algunas propiedades.

La idea consistió en tratar al report como una propiedad objeto, con nombre, cláusulas, tipo de salida, etc. Es decir, crear soluciones flexibles y que sea fácil de mantener, para ello recomienda:

  • No utilizar el Entorno de datos del informe.
  • Emplear las convenciones de nombres
  • Emplear los controles adecuados para la obtención de parámetros a emplear, por ejemplo, options button para elementos excluyentes y casillas de verificación para elementos no excluyentes.

Comentó algunos aspectos relativos a la depuración en informes:

  • Si se produce un error en el informe VFP da información del error; pero no dice qué objeto lo provoca. si estamos en proceso de desarrollo o si tenemos una propiedad para activar la depuración, podemos trabajar desde el diseñador y entonces sí que veremos el objeto que provoca el error.
  • Debemos verificar con mucho cuidado las variables que se van a calcular dentro del informe, especialmente si se emplean múltiples bandas de detalle.
  • Debemos verificar que los datos emitidos por el informe muestran resultados razonables.

Ha sido una sesión muy interesante e instructiva. Muy buena la idea de Barbara de crear contenedores para los distintos parámetros a asociar a cada informe según el o los tipos de salida que se seleccione (no son excluyentes, por tanto usa casilla de verificación). Ha sido un buen ejercicio de trabajo con clases. Tendré que regresar al tema más de una vez.

Llega la hora del almuerzo, del relax y la charla más distendida, aunque sigue siendo Visual FoxPro el tema central de muchas de las conversaciones. Aproveché un momento para pedirle a Andy Kramek y Nancy Folson que me firmaran sus libros respectivos.

Saludos,

Ana

 




Todas las marcas y los logos utilizados en este sitio son propiedad de sus respectivos dueños.
Los artículos, noticias y comentarios son propiedad y responsabilidad de sus respectivos autores.
Copyright © 2000-2007 PortalFox. Todos los derechos reservados.