Resumen del Sábado 22 de Abril - Mañana

PorAmby

El día amaneció con una ligera llovizna, la temperatura se mantuvo agradable y un ligero paseo matutino me ayudó a prepararme para la jornada intensiva que estaba por llegar.

Hoy vimos las Mejores prácticas en: control de errores, diseño de clases, diseño de interfaz de usuarios y trabajo con datos: locales y remotos ... prometía muchísimo y cubrió todas las expectativas.

Comenzó Rick Shumer con Mejores prácticas en el control de errores (Best Practices for Error Handling). El objetivo no era aprender a utilizar un método u otro para en control de errores, el objetivo es mostrar ideas de cómo implementarlo y sobre todo cómo hacer para recibir la cantidad de información necesaria y en la forma más evidente posible para poder corregir los errores.

Rick parte de la base de que hay que programar sobre la base de que vamos a tener errores y esos errores hay que tenerlos previstos, el usuario puede acometer acciones que provoquen errores y tengan como consecuencia que intentemos, por ejemplo usar una tabla sin tenerla abierta previamente, o intentar abrir un fichero inexistente, etc. Pues bien, Rick Shummer mostró una clase que tiene, cuyo objetivo no es tanto el control de errores como tal sino la información que el va a recibir de sus usuarios sobre los errores. La clase consta de un formulario con diferentes fichas donde se almacena la configuración real en la que se ha producido el error, de esta forma cuando el desarrollador recibe del usuario la comunicación sobre que se ha producido un error, es posible reproducir rápidamente las circunstancias en las que se produjo.

Entonces, algunas de las Mejores técnicas planteadas por Rick Shummer u otros expertos presentes como Nancy Folsom y Doug Hennig son:

• implementar en lo posible tratamiento de errores de forma global, pasando todos los parámetros que sean necesarios, para recibir del error la información necesaria. Si se implementa a nivel de objeto, la gran ventaja es el evento Error que dispara VFP.
• con la estructura TRY/CATCH, aprovechar el objeto exception para controlar en varios casos los posibles errores que pudieron ocurrir en el bloque TRY, por ejemplo:
  CATCH TO loException WHEN loException.ErrorNo = n
  donde n es el número concreto que se desea controlar
• tener en cuenta el diseño de patrones, en este caso implementar la cadena de responsabilidad para que los errores sean controlados por quien corresponda
• dejar que los usuarios tengan acceso y puedan leer el log de errores porque puede ofrecer información momentánea
• aprovechar toda la estructura y los comandos que ofrece VFP (ERROR(), LIST MEMORY, LIST STATUS, CREATE VIEW) antes de crear complicados objetos con muchas propiedades. Este objeto será más un problema que una solución, por ejemplo en tratamiento de errores relacionados con escasez de memoria.
• pedir al usuario un juego de datos en los que se produjo el error para poder reproducirlo de la forma más real posible
• emplear lo más posible, además de la llamada telefónica y el correo, Internet para la transmisión de archivos de errores.
• emplear técnicas de captura de pantalla y/o grabado de secuencia de acciones. Una herramienta para grabar, de pago es Camtasia que se encuentra en www.techsmith.com.

Fue muy interesante la presentación de Rick, para mí ha sido el mismo problema desde un enfoque diferente. Para terminar recordemos siempre que el código que NO puede tener errores es precisamente el que se encarga del tratamiento de los mismos y que NO es una práctica ni buena ni aceptable, el dejar de controlar los errores y permitir que el control de errores de VFP sea el que reciba el usuario.

Tuvimos un corto receso que apenas dio tiempo a comprar un par de libros MegaFox y KiloFox que me apetecía muchísimo tener, ambos de Marcia Akins, Andy Kramek y Rick Shummer. Libros excelentes ... y ya puestos, pues compré otro par de Tamar Grannor. En este momento fue cuando tuve el placer de conocer a Hugo Ranea, quien es usuario de PortalFox y miembro de la comunidad, apenas nos saludamos; fue un placer Hugo. Un poquito de charla con Cathy Pountney y Craig Berston y para clase nuevamente ... café en mano, por supuesto.

Era el turno de Marcia Akins quien nos habló de las Mejores prácticas en el diseño de clases (Best Practices for Class Design).
 

Hemos escuchado mucho sobre diseño de clases y aparentemente este es un tema muy trillado y no es así, es un tema muy importante y por eso no podía faltar en esta Conferencia y no podía ser otra mejor que Marcia Akins quien es una gran experta en el diseño de clases.

La presentación se refirió todo el tiempo al ejemplo clásico de un navegador en un formulario sencillo, con una tabla y varios textbox que muestran datos relativos a la dirección de ... pues da igual, de usuario, proveedor, etc. Es difícil encontrar un ejemplo más frecuente que este. En este ejemplo, al escribir el nombre de la persona, txtNombre tiene el código que busca la dirección y la muestra o muestra los controles en blanco para introducir una nueva. Pues bien, al inicio lo mostró sin clases, codificando cada botón del navegador: cmdAnterior, cmdPosterior, etc. Esto no está mal; pero no es buena práctica porque se olvida del todo del diseño de clases.

Hablando de diseño, pues se refirió a tres palabras mágicas aquí: MUST, COULD, SHOULD, que en español, las pudiéramos traducir como DEBE, PUEDE, PODRÍA, ¿y eso qué significa? Pues significa que en el diseño hay que tener en cuenta lo que debe, puede y podría hacer cada elemento. Veamos un par de ejemplos:

• Controlar que la tabla esté abierta - SHOULD - En realidad no es trabajo del navegador, la tabla debe estar abierta para otras tareas del formulario, aunque no está mal verificarlo aquí, se PODRÍA hacer.
• Mover el puntero del registro - MUST - Es el navegador quien TIENE que mover el puntero, nadie más en el formulario.

Al diseñar es necesario tener en cuenta diferentes acciones a realizar: componer, agregar y delegar.

Al diseñar una clase mediante la composición lo que se hace es unir varios elementos en un contenedor y pasar las funciones de control de las acciones al contenedor, en este mismo caso de una dirección, unimos todos los textos y las funciones de encontrar una dirección determinada, a partir, por ejemplo de un nombre de usuario, ya no se realiza por el textbox del nombre sino que este llama a un método del contenedor. De esta forma podemos pegar esta clase compuesta en cualquier caso que necesitemos dirección y con cuidado de controlar bien los parámetros que ha de recibir tenemos garantizada la funcionalidad.

Pero la dirección no tiene exactamente los mismos parámetros en diferentes países y es posible que haya que agregar elementos "al vuelo", pues las dos funciones, NEWOBJECT() y CREATEOBJECT() se encargan de ello.

Y en tercer caso, es cuando nos olvidamos por completo de programar en en el contenedor, o en cada elemento del mismo y delegamos todas las funciones a una clase externa, que se encarga de todo, en ese caso tenemos, por ejemplo, un botón buscar que hereda de un botón Action que hereda a su vez de una clase session, genérica, que exige mucho cuidado en su programación y tener en cuenta las diferentes circunstancias en las que puede ser llamada, la recomendación es tener mucho cuidado con los parámetros, ni muchos ni pocos, los necesarios.

Marcia habló de varios aspectos más y contó con el apoyo de Andy Kramek, Tamar Grannor y Doug Hennig quienes aportaron sus experiencias personales.

Nos despedimos de Marcia agradeciendo la forma amena de presentar el tema. Llegó la hora de almorzar. Fue un almuerzo tranquilo, sin keynotes, ni tareas, un descanso, que compartí con Hugo Ranea, su jefe y un grupo de participantes más. Hablamos de nuestras participaciones en eventos, de los futuros eventos, tanto en EE.UU. como en Europa, hablamos de Fox y de .NET, en este evento, no hay sesiones de .NET, no hay interoperabilidad ... creo; pero en el salón de al lado hay una conferencia cuyo tema es "Lo mejor de .NET", y es lo que pone en grande en las credenciales de los participantes.

Will Helzen tuvo un acierto al poner bien grande los nombres, se agradece, es muy fácil identificar a la gente ... aunque claro, no dice nada sobre Fox ... bueno, en la mía si, creo que seré la única :), mi credencial pone PortalFox !!! Yupi yupi !!! Estoy en una conferencia de Fox.

Aproveché para hablar con Nancy Folsom (foto), porque yo no había entendido una sugerencia que hizo en el tema de depuración y resultó que era emplear CREATE VIEW, ah bien, es un comando muy bueno que nos permite conocer el entorno actual.

Saludos,

Ana