Está liberada la versión v2.4.17 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:
Agregado switch "nFlags" en los scripts vbs para Plastic, para poder mostrar un mensaje de finalización de proceso, muy útil cuando se procesan muchos archivos o cuando se procesan archivos pesados que tardan (activo por defecto)
Activado por defecto el mensaje de finalización de proceso en los scripts vbs para usar con el administrador de archivos de Windows
Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.23
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Nota: Los fuentes de FoxBin2Prg están en CodePlex, en el link indicado arriba en la versión.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v1.19.23 de FoxBin2Prg con los siguientes cambios:
Mejora: Los valores de los campos timestamp y uniqueid vuelven a los binarios. En los tx2 es configurable con los flags NoTimestamps y ClearUniqueID. En la v1.19.7 se introdujo la posibilidad de vaciar los timestamps de los binarios y tx2 con el switch NoTimespamt, y en la v1.19.10 se introdujo el flag ClearUniqueID para hacer lo mismo con los UniqueID. Desde esta versión esos campos se dejan con valor en los binarios siempre y los switch solo afectarán a los textos tx2 generados desde los mismos. El motivo es evitar diferencias innecesarias en los binarios, ya que si, por ejemplo, un proyecto PJX tiene estos campos vacíos y se abre el proyecto (con MODIFY PROJECT), aunque no se toque nada y se cierre, FoxPro completa varios de estos campos automáticamente, lo que produce diferencias que luego salen en el control de código como binario modificado.
Mejora: Agregado valor de sccdata por defecto. Este es otro campo que se dejaba vacío, pero que al abrir ciertos componentes con MODIFY, aunque no se modifiquen, FoxPro les rellena este campo con el valor por defecto. Desde esta versión los binarios regenerados tendrán este campo relleno con el valor por defecto, así FoxPro no lo rellena por su cuenta y se evitan diferencias en los binarios por este motivo.
Bug Fix: Arreglo de evaluación de la fecha para incluir los archivos ??T (vct, frt, mnt, sct, lbt). En la v1.19.21 se introdujo una mejora en la regeneración de archivos, controlada por el switch OptimizeByFilestamp (activa por defecto en foxbin2prg.cfg), en la que se optimizaba su creación dependiendo del timestamp de los archivos TX2 y de los archivos ??X. El problema es que si se modifica, por ejemplo, el backcolor de un form y se guarda, el archivo actualizado es el memo (SCT) y no el SCX, por lo que el archivo SC2 no se regeneraba, pudiendo perderse el cambio si se regeneraba el binario desde el mismo. Ahora se compara también el timestamp de los archivos .??T (memo), para evitar este problema.Esto solo afecta las instalaciones que tengan OptimizeByFilestamp = 1 en foxbin2prg.cfg
Bug Fix: Agregada propiedad faltante "BorderColor" en props_optiongroup.txt.No hubo ningún reporte de error por esto, pero faltaba en la lista y fue agregada.
Bug Fix: Agregada props Stretch en props_image.txt (Kenny Vermassen). La ausencia de esta propiedad en la lista de propiedades provocaba en ciertas situaciones que algunas imágenes se redimensionen mal, dependiendo del valor de la propiedad Stretch y del tamaño de la imagen.Esto solo afecta a los forms o clases que usen imágenes más grandes que el tamaño asignado al height/width del control image que las contiene.
Bug Fix: Agregada props Enabled en props_image.txt. No hubo ningún reporte de error por esto, pero faltaba en la lista y fue agregada.
Como actualizar el FoxBin2Prg existente:
Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v2.4.16 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:
- Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.22
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Nota: Los fuentes de FoxBin2Prg están en CodePlex, en el link indicado arriba en la versión.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v2.4.15 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:
- Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.21
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Nota: Los fuentes de FoxBin2Prg están en CodePlex, en el link indicado arriba en la versión.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v1.19.21 de FoxBin2Prg con los siguientes cambios:
Agregado soporte para convertir a texto o binario todos los archivos de un proyecto desde pjx o pj2 (Matt Slay). Gracias al feedback en el foro Google de Thor (Proyecto VFPx), me comentaron que sería útil poder pasar todos los archivos de un proyecto PJX a texto (y viceversa), por lo que se agregó esa posibilidad. Para hacerlo, se debe ejecutar desde la ventana de comandos: DO foxbin2prg WITH "<path>\proyecto.pjx", "*" . El último asterisco hace la diferencia entre el proyecto solo o todos los archivos del proyecto.
Optimización de búsqueda del programa de capitalización al procesar proyectos. Junto al nuevo soporte anterior, hay una optimización para no buscar una y otra vez por cada archivo escaneado si existe el programa de capitalizaciones, lo que implica un acceso extra al disco, por lo que ahora se cachea en memoria al inicio del escaneo.
Agregado AGAIN a la apertura SHARED de las tablas, para permitir concurrencia (Jim Nelson).
Agregada optimización basada en la la fecha/hora de modificación de los archivos para regerenar solo los archivos binarios y tx2 modificados (Matt Slay). Esta optimización puede mejorar mucho los tiempos de generación de los archivos binarios o tx2 de un proyecto o directorio, ya que solo se generarán los que hayan cambiado desde la última generación. Esto se hace comparando los timestamps de cada binario y su tx2, y fue sugerido por Matt Slay en el foro de Thor.
Agregada traducción al inglés en foxbin2prg_en.h del mensaje de LOG para la nueva optimización
Simplificación de la sección <DefinedPropArrayMethod>: Los métodos y arrays ya no requieren los símbolos * y ^ delante. Hasta ahora, en esta sección los métodos llevaban "*" por delante, y los arrays llevaban "^", ya que así es como está guardado en la tabla. Desde esta versión ya no requieren llevar esos símbolos por delante, y tampoco se generarán en los tx2, solo se generarán al actualizar los binarios. Esto mejora y simplifica el mantenimiento de este bloque. Igualmente se mantiene la compatibilidad con los archivos tx2 existentes que tengan esos símbolos.
Como actualizar el FoxBin2Prg existente:
Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v2.4.14 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:
- Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.20
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Nota: Los fuentes de FoxBin2Prg están en CodePlex, en el link indicado arriba en la versión.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v1.19.20 de FoxBin2Prg con los siguientes cambios:
Nuevo: Relativización del path de los CDX dentro de los DB2. Hasta ahora, cuando se generaba el DB2 de un DBF, el CDX se generaba con una ruta absoluta, lo que es un problema si 2 personas tienen la misma tabla sin cambios pero en distintos directorios, porque al hacer checkin en un SCM se generan cambios que no son reales ni importantes. Ahora estas diferencias no se general.
Nuevo: Recompilación del EventsFile del DBC, si existe, para evitar errores al regenerar el DBC. Si el DBC tiene un archivo PRG de eventos asociado, se genera el DB2 y se cambia a otro directorio, al regenerar el DBC desde el nuevo directorio, puede dar errores de que no se encuentra el archivo PRG de eventos, aunque esté copiado allí. Lo que se hace ahora es recompilar ese PRG y luego regenerar el DBC desde el DB2, lo que evita el error.
Como actualizar el FoxBin2Prg existente:
Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v2.4.13 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:
- Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.19 - Actualizada la configuración en el README.txt, ya que un error en lo escrito estaba causando algunos problemas en la configuración del merge
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Nota: Los fuentes de FoxBin2Prg están en CodePlex, en el link indicado arriba en la versión.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Está liberada la versión v2.4.12 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:
- Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.18
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Nota: Los fuentes de FoxBin2Prg están en CodePlex, en el link indicado arriba en la versión.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
Estas
herramientas son un grupo de scripts vbs y programas Visual FoxPro 9
que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg
(incluye solo el EXE) desde dentro de la interfaz de Plastic.
El README.txt explica como se configura en Inglés y Español.
Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.
[Actualizaciones] 01/03/2014 - Agregado apartado sobre las herramientas de productividad incluidas (scripts .vbs) 26/02/2014 - Agregada aclaración sobre el merge del minuto 00:29:48 del video --------------------------
Por: Fernando D. Bozzo
En esta nota voy a comentar cómo sería el trabajo con control de código fuente y FoxBin2Prg. Aunque el ejemplo es con PlasticSCM, la operativa general en el desarrollo se aplica a cualquier SCM.
Primero una breve mención a SourceSafe
Para quienes lo sigan usando, les recomiendo pasarse cuanto antes a cualquier otra herramienta SCM. El motivo principal es que Microsoft ya no soporta este producto, cuya última versión es de 2005 (Visual SourceSafe 2005, versión que muchos desconocen) y una gran mayoría de los que lo usan siguen con la que salió en Visual Studio 6, que es del año 1998 más o menos!
Tiene, además un gran problema de escalabilidad y para mantener el histórico de los archivos, cosa que en un SCM es algo crucial. Simplemente es demasiado fácil borrar archivos del historial sin querer o por problemas internos, y no son recuperables.
Si a pesar de la advertencia no les queda otra que seguir usándolo, sepan que FoxBin2Prg se integra bién con el mismo gracias al archivo de configuración foxbin2prg.cfg y la reasignación de extensiones, de hecho, permite usarlo para hacer el merge de los binarios como nunca lo habíamos visto ;-)
Ahora sí, a lo que nos ocupa
En esta ocasión voy a comentar sobre el trabajo con PlasticSCM, una herramienta SCM de pago, pero que permite su uso gratuito a cualquier persona o grupo de hasta 15 miembros y que se use para controlar el código de cualquier tipo de aplicación comercial o de uso interno. Solo es necesario registrarse con un email válido, descargarse la última versión (sacan una cada 2 semanas o menos) y generar y descargarse el archivo de licencia de 15 usuarios que debe renovarse cada 6 meses de forma gratuita.
El programa es multiplataforma (Windows, Mac, Linux [con WINE]) e incluye el componente cliente y servidor, pudiendo instalarse ambos o uno solo, ya que por defecto utiliza Microsoft SQLCE 3.5 en Windows (hasta 4 GB por base de datos) y SQLLite en Linux. El backend es configurable, soportando SQLServer, MySQL, Postgress y otras bases de datos, lo que permite instalar el componente cliente en un PC y el componente servidor en un servidor dedicado, aunque también se pueden instalar ambos componentes en la misma PC de desarrollo (yo lo uso así).
La configuración usada ha sido la de usuario/password manejada desde el gestor de usuarios incluido, pero permite varios esquemas de autenticación, incluyendo LDAP, Directorio Activo y otros.
La configuración interna que usé para trabajar es esta:
Estas son las herramientas en Visual FoxPro preparadas para trabajar con PlasticSCM (todo lo necesario, incluyendo el ejecutable v1.19.12 de FoxBin2Prg): https://github.com/fdbozzo/foxpro_plastic_diff_merge (el README.txt explica como configurarlas, tanto en Español como en Inglés)
FoxBin2Prg puede ser usado con la interfaz SCCAPI 1.0 (la que usa SourceSafe) o solo, pero recomiendo usarlo solo, o sea, no usar la integración de Visual FoxPro con SCCAPI, ya que limita mucho lo que se puede hacer, y sobre todo la forma de trabajar.
SCCAPI
estaba pensada (o configurada) para bloquear los archivos cuando se
desprotegen, lo que impide que otros desarrolladores puedan trabajar con
el mismo archivo. Esto en un entorno de desarrollo local o distribuido
no es escalable, ya que se depende de que quien tenga el archivo
bloqueado lo libere cuando pueda o quiera, y un desarrollo no puede
depender de eso.
Trabajar sin la integración
FoxPro/SCCAPI tiene muchas ventajas, aunque para quienes venían
trabajando de esa forma (yo incluido:) les pueda resultar algo no
natural al principio, ya que implica un cambio de mentalidad, pero que
con la práctica se puede comprobar que es mejor, y como ventaja
adicional, los proyectos abren mucho más rápido, como ha sido siempre
para los proyectos que no están bajo control de código integrado con SCCAPI.
Video del ejemplo usado en este post:
Esquema de trabajo en FoxPro con un SCM
La que voy a describir es la forma de trabajar que encontré más cómoda, pero no es la única, y se basa en el trabajo en rama por tarea, un concepto en el que ya hablaban los de Coding Horror allá por 2007. Esto quiere decir que para cada tarea se hace una rama, se trabaja en ella, y cuando se finaliza la tarea y las pruebas unitarias, se integra en la rama principal o en la de testing integrado.
En nuestro ejemplo hay dos desarrolladores, Dev_1 y Dev_2. Se comienza partiendo desde la rama principal o Trunk (/main en el ejemplo), que contiene la última versión estable del proyecto, en este caso la v1.0, se la que se crea una rama de testing integrado, llamada "TESTS" en este caso, y cada desarrollador se crea una rama particular de trabajo desde la v1.0
Si hubiera más desarrolladores, la mecánica sería la misma, cada uno se crea su propia rama partiendo de la última Release estable.
Luego se hace el desarrollo, cada uno por su lado, con la seguridad de que ninguno interferirá con el otro, en el sentido de bloquear al otro, como pasa en SourceSafe.
El video muestra como cada desarrollador tiene que hacer una serie de modificaciones en los mismos componentes (el peor caso), siendo estos un form, una librería de clases, un reporte, un report label y un menú.
Dev_1 tiene que agregar un campo de Costo en la página DATOS de un pageframe de un form:
Dev_2 tiene que agregar una nueva página CALCULOS al mismo pageframe del mismo form:
Este form usa la clase form_bus de una libreria de clases de negocio llamada test.vcx
La librería tiene un método existente, pero cada desarrollador necesita agregarle un método. Dev_1 necesita agregarle el método set_Costo_Articulo() y Dev_2 el método set_PrecioArticulo(). Cada uno hace sus pruebas por separado, y finalmente integran sus cambios en la rama TESTS para poder hacer pruebas integradas entre Dev_1 y Dev_2 antes de que suba todo a la rama principal.
Para hacer el check-in del código se deben generar las vistas de texto con FoxBin2Prg.
[Actualizado - 26/02/2014 >>]
Respecto del merge manual, cuando toca hacerlo, en la vista de Merge se muestran tanto las versiones texto como los binarios. Como en esta operación lo que "manda" son las versiones texto, ya que son las que se mezclan visualmente, hace que los binarios se deban pasar "como están" a la vista de cambios pendientes, y por eso se puede ver como en el minuto 00:29:48, una vez terminado el merge de los tx2 se seleccionan los binarios que quedan y se elige "Merge keeping workspace changes" o "Mezclar manteniendo los cambios del workspace". Esto los deja en el panel de "Pending Changes" o "Cambios Pendientes", donde se regeneran desde las versiones tx2 recién mezcladas para mantenerlos sincronizados. [<<]
Se debe tener cuidado de que las librerías, forms, etc, no estén abiertas en alguna sesión de FoxPro, porque si no será imposible para FoxBin2Prg abrir el archivo para realizar su trabajo, y mostrará un error, además de generar un .ERR para el archivo en cuestión. Por ello, recordar hacer CLEAR ALL/ CLOSE ALL antes de las conversiones.
Regenerar los binarios de esta manera tiene otra ventaja: Para quienes tengan librerías de clases o forms de varios años y con muchas modificaciones o que han pasado por muchas manos, les habrá pasado de que a veces se pueden comportar de forma extraña o dar errores, o el clásico "agrego un código en un método pero se sigue ejecutando el método viejo!", que es una de las formas más raras de corrupción de una clase o form. En estos casos, el paso a texto y posterior regeneración del binario soluciona algunos problems, y en todo caso, por lo menos se puede ver e código en claro y reparar como un PRG!
Con esta forma de trabajo además no es necesario que se pongan como ReadOnly los archivos a modificar. Solo se hace el check out de binarios y versiones texto a modificar, se hacen las modificaciones, se generan las versiones texto (las llamo TX2), se regeneran los binarios, se hacen algunas pruebas para comprobar que ha ido todo bien y se procede al check in final (binarios y texto). Lo de mantener ambos archivos es por seguridad y por performance. Por seguridad, porque donde se trabaja realmente en diseño es sobre el binario y siempre es bueno tenerlo por si acaso, ya que FoxBin2Prg sigue siendo beta hasta que tenga el suficiente tiempo en uso como para considerarlo versión final, y por performance es porque si el proyecto tiene muchos archivos y solo se guardaran las versiones texto, al hacer el ejecutable final en un servidor de integración (o a mano), habría que sumar el tiempo de regeneración de todos los binarios, lo que podría demorar un rato.
En este punto de comprobar si está todo bien, puede que se quiera hacer un ejecutable para comprobarlo, y obviamente esto provoca que se recompilen todos los binarios y que figuren como modificados ante el control de código fuente. No pasa nada, se pueden comprometer los ficheros cambiados o solo comprometer los que se les haya hecho el check-out previo y deshacer los cambios del resto.
Lo que realmente importa es que para la versión definitiva sí se debe recompilar todo, ya que FoxBin2Prg intenta hacerlo de la mejor forma, pero si se invoca la regeneración de binarios desde el explorador de archivos, FoxBin2Prg no puede saber cuál es el proyecto al que corresponde cada archivo, por lo que lo recompila desde su ubicación, y como consecuencia puede que los archivos #include o referencias a componentes a rutas relativas no se encuentren, dando errores de compilación. Por eso es que siempre se debe realizar una compilación de todo el proyecto en la fase final o de pruebas, así estos problemas desaparecen
Lo de recompilar los binarios al regenerar se hace porque si no hay propiedades o métodos que de otra forma no se ven en tiempo de diseño, aunque realmente estén ahí. Es una cosa extraña, pero sé que pasa y así es como se soluciona, aunque esa compilación provoque los errores comentados.
Si por alguna causa no ha salido todo bien y ha ocurrido algo con el binario, se puede recuperar desde los .BAK que se generan para cada extensión o desde la propia herramienta SCM. La cantidad de .BAK que se hacen por defecto es 1, pero se pueden hacer más si se requiere, indicándolo en el archivo de configuración foxbin2prg.cfg
Vámonos por las Ramas, pero no matemos al Integrador!
La rama TESTS podría no ser única y solo simboliza una rama previa a la principal donde un grupo de desarrolladores que están trabajando en un proyecto determinado hará su integración de código. Podría llamarse "integración_proyecto_X" o de cualquier otra forma, pudiendo haber una rama por cada proyecto independiente.
En el caso de múltiples proyectos que deban integrarse, se puede crear una rama de integración adicional, previa a la "TESTS" de nuestro ejemplo, de modo de repartir el trabajo de integración equitativamente entre los desarrolladores y el integrador principal (debería haber uno) que además es el encargado de verificar el código y los requisitos no funcionales.
Si hay mucha integración, este reparto de trabajo de integración es necesario para "no matar al Integrador", ya que la responsabilidad es muy grande y también lo es la posibilidad de cometer errores, y el Integrador también es humano :-)
Cualquiera que haya realizado esa tarea sabe de lo que hablo.
¿Pero entonces cada desarrollador sube lo que quiere?
No, cada uno trabaja en lo que tenga asignado. El proyecto en el que están trabajando puede haber comenzado hace meses, por ejemplo en la v0.1, pero cuando finalizan conviene que hagan su entrega de código integrándola en una rama de Integración que se crea basada en la última versión estable de Producción, ya que nadie mejor que los desarrolladores para saber qué código debe estar presente sí o sí. De esa forma cargan con una parte de la integración que corresponde a las versiones intermedias que hayan pasado y pueden comprobar que sus cambios funcionan bien antes de pedir la integración definitiva, y es en este "pedir" donde entra en acción el Integrador principal, que gracias a que le entregan el código integrado en la última rama estable los únicos cambios que verá son los realizados por ese proyecto y no tendrá que lidiar con las diferencias entre las distintas versiones, ya que esa parte fue resuelta antes, y eso le permite hacer su trabajo mejor y más rápido y no debe soportar la carga de todo.
Tenemos una librería que se modifica demasiado!
Siempre puede pasar que haya una o varias librerías que tengan un tamaño apreciable y muchos, muchísimos métodos y clases que se están cambiando todo el tiempo y que incluso con FoxBin2Prg muestran muchos cambios y es difícil de integrar: ¿Qué hacer en este caso? Cuando ocurre eso es porque no se ha previsto su crecimiento o porque se le han hecho modificaciones por muchas manos que no se han animado a hacer lo que se debió hacer desde un principio: Refactorizar
La única solución posible que dará mayor seguridad a futuro y bajará los costes de mantenimiento que cada vez son mayores con cada nuevo cambio es refactorizar como parte del trabajo diario y no sólo cuando las cosas van mal, porque en ese momento ya es tarde y hasta podría ser imposible o demasiado costoso acometer esta tarea postergada miles de veces.
Algunos consejos
Aunque en los requisitos no funcionales se suele incluir la encapsulación y la nomenclatura de variables y objetos, lo cuál no siempre se respeta, en la integración de código esto juega un papel fundamental, ya que cuanto más se respeten estas recomendaciones más fácil será la integración.
Un ejemplo: si en un form se dejan todos los objetos con su nombre por defecto y el form usa pageframes o uno con varias páginas, cuando al momento de integrar toque hacer un merge eso será lo que se vea: pageframe1.container1.textbox1, pageframe1.container1.textbox2, etc. ¿Cómo puede el integrador hacer bien su trabajo si ni siquiera sabe para qué son esos controles cuyo nombre no indican nada respecto de su función u objetivo?
Otro: Dentro de varios "textbox1" que hay en un form, resulta que se requiere en tiempo de merge cambiar uno de sitio o de nombre, debiendo porque resulta que ambos desarrolladores han tenido que agregar uno o más controles y los dejaron con sus nombres por defecto, de modo que el integrador se encuentra con dos objetos con el mismo nombre. ¿Cuál es el bueno? Y si hay que renombrar uno, ¿cómo identificar sus métodos y no confundirlos con el otro?
Una razón más: La nomenclatura correcta permite que las diferencias sen mucho menos, y esto implica dedicar menos tiempo y tener mayor seguridad sobre lo que se está integrando.
Creo que queda claro el problema, y tanto en el video como en la captura anterior se puede ver que uno de los motivos por los que no tuve mayor problema en hacerlos rápido, incluso mezclando los mismos métodos o controles, es gracias a usar una nomenclatura correcta donde cada objeto y variable tiene su nombre con un significado de para qué sirve.
Trabajo yo solo, ¿tiene sentido usar Control de Código?
¡Por supuesto! No solo porque de paso se tiene un backup, sino porque se pueden aprovechar las herramientas relacionadas al SCM, como la herramienta de Diff y Merge. La de Merge no será mayor problema porque al trabajar solo nunca habría conflictos para resolver y todos los merge serán automáticos, pero a la de Diff es a la que mayor provecho se le sacaría, ya que permite ver las diferencias entre las distintas versiones de un programa y eso permite encontrar los errores o las modificaciones realizadas mucho más rápido. Además de todo esto está la historia: Todo lo que se guarda en control de código fuente tiene historia, con lo cuál se puede identificar si una modificación o un error es de hace un mes o de hace 10 años.
[Actualizado - 01/03/2014 >>]
Herramientas de productividad incluidas (scripts .vbs)
Conversando
con distintos desarrolladores veo que no todos leen el Readme.txt y la
cabecera de los scripts .vbs incluidos.
Respecto de FoxBin2Prg en particular, en el artículo "FoxBin2Prg: Detalle de vistas, datos de uso, configuraciones y más", en la última parte de Palabras Finales se describe como agregar los scripts incluidos en el menú "Enviar A" para poder usarlos desde el menú contextual del explorador de archivos. [<<]
Notas finales
Seguramente me esté dejando algunas cosas fuera porque el tema es extenso, pero si fuera así no descarten que lo agregaré aquí mismo para que quede lo más completo posible.
Cualquier duda o pregunta, por favor no se corten y pregunten, ya sea en el blog, en el foro Google de FoxPro o por correo, que esto se trata de probar, equivocarse y aprender.
Preparé un pequeño veideo de muestra en YouTube sobre un merge de un form.
No pretende mostrar una forma de trabajar, sino solo un merge que suele ser lo más complejo (y en Fox, que yo sepa, imposible hasta ahora)
Al próximo le pongo el sonido :-) Bueno, finalmente pude ponerle algo de música, gracias a Google :-)
Está liberada la versión v1.19.10 de FoxBin2Prg con los siguientes cambios:
Agregada parametrización para el soporte de conversión permitido por cada tipo de archivo (0=Ninguno, 1=Solo TX2, 2=TX2 y Binarios) en foxbin2prg.cfg. Esto permite habilitar o deshabilitar ciertos tipos de conversión. Por ejemplo, si se quisiera habilitar la generación de DBFs, además de permitir la de DB2 (versión texto), se debe poner DBF_Conversion_Support = 2 (por defecto ahora es 1 para evitar la pérdida accidental de datos). Sirve para lo mismo que NoTimestamps, para minimizar las diferencias entre archivos al comparar.
Arreglo de seteo NoTimestamps por defecto
EXPERIMENTAL: Nuevo parámetro de configuración "ClearUniqueID" en foxbin2prg.cfg para borrar el UniqueID de los binarios y versiones texto. Funciona bien y aparentemente FoxPro no hace uso del UniqueID, pero requiere más pruebas. Para usarlo se debe poner ClearUniqueID = 1 en el foxbin2prg.cfg
Ajuste de algunos casos de prueba FoxUnit
Nota: En el archivo foxbin2prg.cfg están documentados los parámetros permitidos.
A qué afecta:
A la generación de binarios y de versiones texto.
[18/04/2015: Actualizado hasta la versión v1.19.42]
Por: Fernando D. Bozzo
Creo que sería un buen comienzo empezar este blog con una nota sobre FoxBin2Prg, un proyecto Open Source actualmente hospedado en CodePlex dentro del proyecto VFPX y que comencé a fines de noviembre de 2013, por la necesidad de no solo generar vistas texto de los binarios de Visual FoxPro 9 como ya hace el scctext, sino de mejorarlo a tal punto que para el Desarrollador sea como el código mismo, y que además permita ser usado para hacer Diff, Merge y de paso Backup del código.
Ventajas:
Genera archivos estilo "PRG" (no compilables), para comparación visual
Permite hacer cambios en la versión TEXTO tan fácil como modificar PRG
Todo el código de programa está en un solo EXE, para simplificar su copia y mantenimiento
Con las versiones TEXTO puedes regenerar los binarios originales, así que es útil como backup
Las extensiones usadas son configurables si se crea el archivo FOXBIN2PRG.CFG
Los métodos y propiedades de la versión TEXTO son ordenados alfabéticamente para acilitar su comparación
Tiene compatibilidad con el SccText(X) a nivel de parámetros, así puede ser usado como su sustituto con SourceSafe
Actualmente
se soporta la conversión de archivos PJX,SCX,VCX,FRX,LBX,DBC,DBF y MNX,
para los que genera versiones Texto con extensión
PJ2,SC2,VC2,FR2,LB2,DC2,DB2 y MN2 que pueden ser reconfiguradas para
compatibilizar con SourceSafe.
Ejemplo de archivo de configuración FOXBIN2PRG.CFG si necesita cambiar extensiones
Usando la versión "EXE": (útil para ser llamado por programas de 3ros)
FOXBIN2PRG.EXE "<path>\file.scx" ==> Genera la versión TEXT con extensión sc2
FOXBIN2PRG.EXE "<path>\file.sc2" ==> Regenera el binario con extensión scx
Usando la versión "PRG":
DO FOXBIN2PRG.PRG WITH "<path>\file.scx" ==> Genera la versión TEXT con extensión sc2
DO FOXBIN2PRG.PRG WITH "<path>\file.sc2" ==> Regenera el binario con extensión scx
Usando la versión "Objeto":
LOCAL loCnv AS c_foxbin2prg OF "FOXBIN2PRG.PRG"
loCnv = NEWOBJECT("c_foxbin2prg", "FOXBIN2PRG.PRG")
loCnv.Ejecutar( <params> )
El código generado
Para cada tipo de binario Fox hay una vista personalizada, pensada para sacarle el mayor provecho a cada uno. Por ejemplo, para los DBFs y DBCs (tablas y bases de datos nativas) se generan vistas estilo XML
y para el resto se genera código de programa y seudocódigo, que no compila, pero es tan fácil de leer como el código normal, con la ventaja de que en todos los casos se pueden hacer modificaciones que luego se trasladarán al binario regenerado.
Estructura de clases
Todo el código está en un único programa dividido en varias clases:
Una clase principal llamada c_foxbin2prg, de tipo session, que es la que recibe los parámetros
Una para el indicador de avance cuando se procesan varios archivos llamada frm_avance
Una para cada tipo de conversión específica, que es cargada por la clase principal y que están basadas o en c_conversor_bin_a_prg o en c_conversor_prg_a_bin
Unas cuántas de soporte basadas en cl_col_base y cl_cus_base para poder completar los datos de cada unidad o subunidad de información.
Por ejemplo, el conversor de DBF a texto, además de la clase conversora principal, utiliza:
Una clase para la información del DBF (cl_dbf_table)
Una clase para la información de campos (cl_dbf_field)
Una clase para la información de índices (cl_dbf_index)
2 clases de colección (cl_dbf_fields y cl_dbf_indexes)
Funcionamiento
Cuando se pide convertir un VCX a VC2, ocurre lo siguiente:
La clase c_foxbin2prg recibe los parámetros de entrada en el método execute(), siendo el primero de ellos el nombre y ruta del archivo a convertir. En este paso también se hacen algunas validaciones
A continuación se llama al método convert(), que selecciona el conversor a utilizar de acuerdo al tipo de archivo pasado, en este caso es c_conversor_vcx_a_prg, se instancia la clase, se le pasan los datos necesarios y se invoca a su método Convertir()
El método Convertir() abre la librería VCX como una tabla en modo SHARED NOUPDATE con alias TABLABIN y a partir de allí se recorren todos los registros, invocando a métodos intermedios específicos para tipo de dato del VCX que irán analizando los datos del registro e irán generando cada uno su parte de información de texto, como la definición de la clase, el ordenamiento alfabético y definición de las propiedades al inicio, el ordenamiento alfabético y definición de los métodos, etc.
En los distintos métodos se va obteniendo, formateando y escribiendo trozos de código, y todo el código/texto generado se va guardando en una variable pública llamada C_FB2PRG_CODE, que al finalizar se escribe en el archivo VC2.
Cuando se pide regenerar un binario desde el VC2, ocurre lo siguiente:
Se realizan los dos primeros pasos del proceso antes descripto, pero instanciando la clase c_conversor_prg_a_vcx
En el método convert() se invoca a identifyExclusionBlocks() que analiza el código del VC2 buscando los #IF .F. y los TEXT..ENDTEXT, para saber que dentro de esos bloques no debe analizar nada
Se llama al método identifyCodeBlocks() que a su vez llama a los distintos métodos analyze que se encargan de analizar secciones específicas de código como los ADD_OBJECT, DEFINED_PAM (las propiedades, arrays y métodos definidos por el usuario), HIDDEN, INCLUDE, METADATA y demás secciones del código, cada una de las cuáles realiza un parseo específico para completar las propiedades del objeto de datos que le corresponde
Finalmente se invoca al método writeBinaryFile() que recorre toda la información recolectada antes y escribe el binario
Control de errores
El control de errores se basa en Try/Catch, donde cada método controlado se encarga de 2 cosas:
Tratar el error, generar la información de Log necesaria y limpiar el entorno modificado (garbage collect)
Relanzar el error hacia el nivel superior, que llegará finalmente hasta la capa más externa que es la clase principal, donde dependiendo del modo de llamada de foxbin2prg (EXE, PRG u Objeto) devolverá un tipo de información u otro.
Por ejemplo, en modo EXE se devuelve un código de error 1 como resultado de ejecución, valor que puede ser leido por un BAT o un script VBS con ERRORLEVEL para tomar alguna decisión o realizar alguna acción.
Parámetros
Finalmente, los distintos parámetros de entrada permiten configurar cómo se desea que funcione y actúe ante ciertas situaciones:
tc_InputFile: Nombre completo del archivo de entrada a convertir
tcType_na: Mantenido por compatibilidad con SourceSafe. Por ahora sin uso.
tcTextName_na: Mantenido por compatibilidad con SourceSafe. Por ahora sin uso.
tcGenText_na: Mantenido por compatibilidad con SourceSafe. Por ahora sin uso.
tcType_na: Mantenido por compatibilidad con SourceSafe. Por ahora sin uso.
tcDontShowErrors: Un "1" indica que no se quiere mostrar errores si llegaran a ocurrir. Esto es útil en un procesamiento batch, donde no se quiere que los errores interrumpan el proceso ya que se loguean a un archivo .LOG o .ERR que se puede revisar luego
tcDebug: Un "1" indica habilitar el modo de depuración, que solo se usa en modo desarrollo cuando se ejecuta el PRG y que permite que se abra una ventana de DEBUG para depurar el error en el mismo sitio donde ocurrió, inspeccionar las variables y ver lo que sea necesario. En tiempo de ejecución (EXE) solo habilita el modo de generación de LOG, que también se puede habilitar creando un archivo FoxBin2Prg.log junto al EXE
tcDontShowProgress: Un "1" indica que no se quiere mostrar una barra de progreso cuando se procesa un lote de archivos. Para un único archivo no se muestra esta barra de progreso.
tcOriginalFileName: Este parámetro fue uno de los últimos agregados, y está especialmente pensado para trabajar con herramientas SCM, donde la mayoría de las veces se generan los archivos en ubicaciones temporales (c:\temp) y con nombres temporales (fffds-44343-ffds5-fsdfe.vcx). Gracias a este parámetro el conversor sabe el nombre original del archivo y lo puede utilizar en sitios donde queda registrado, como la cabecera de los TX2 y algunas propiedades importantes. Por ejemplo el PJ2 tiene unas cuántas referencias a su nombre en distintas propiedades, que sin este parámetros tendrían un nombre temporal que impediría regenerar el binario con el nombre correcto.
tcRecompile: Indica si se debe recompilar, o no. Por defecto, desde la v1.19.4 ya no recompila, salvo que se indique '1' para recompilar desde el directorio del binario (como hacía antes) o un 'Path' para recompilar desde el mismo. Lo mejor es undicar el Path del proyecto PJX, ya que siempre que se usa un proyecto, los componentes que se agreguen se compilan desde esa ubicación relativa, y todos los arhivos se vinculan de forma relativa, como los Include (..\include\foxpro.h), que se se compilaran desde otra ubicación darían errores de compilación, que es lo que ocurría con el funcionamiento anterior de FoxBin2Prg cuando se referenciaban archivos externos de forma relativa.
Omití varios detalles para no hacer el post muy largo, pero quería explicar un poco por encima el funcionamiento de este programa y su estructura. Probablemente en próximos posts hable sobre algunas particularidades más específicas y de algunas técnicas de programación utilizadas.
