viernes, enero 26, 2018

PBF: Metodología de Desarrollo bastante usada y no reconocida

Como sabemos, hay varias metodologías de desarrollo que han evolucionado desde sus comienzos hasta la actualidad, hagamos un breve repaso de ellas (definiciones tomadas de Wikipedia):


1970



1980



1990



2000



2010




Persistentes en el tiempo

Varias metodologías antiguas han desaparecido o ya casi no se usan, y hay metodologías que han comenzado alrededor del año 2000 y que han ido madurando en el tiempo, siendo (a día de hoy) las siguientes:


Pero hay una que no sale en nigún sitio, que no está documentada, con una (lamentablemente) larga fila de seguidores, y que creo que más de uno habrá visto, aunque no supiera su nombre:


Programación Basada en la Fé (PBF)
No hay link justamente porque formalmente no existe, pero está ahí...

¿Cómo funciona?
Es fácil: se hacen desarrollos en modo "para ayer", donde no hay tiempo para detenerse a comprobar la calidad o hay un mínimo de tiempo para algunas pruebas poco fiables porque ese tiempo de pruebas se ha ido reduciendo para poder meter alguna característica más.

¿Y las pruebas automatizadas?
Bien, gracias. Si hay suerte, puede que haya algunos tests semi-automatizados de hace varios años, cuando en algún momento había tiempo para los mismos, con lo que al ejecutarlos ahora podemos comprobar que algunas especificaciones de hace muchos años aún funcionan, pero de las nuevas no sabemos nada.

Obviamente, esta metodología genera muchas incidencias y los usuarios las reportan, y hete aquí dos puntos fuertes de esta metodología:

  1. Cada cierto tiempo las incidencias abiertas "se cierran", aún sin estar seguros de que se corrigieron, sobre todo las más antiguas o sangrantes, todo sea por que salgan bien las estadísticas. Si la incidencia no se reabre quiere decir que se ha acertado con la solución y que se puede seguir así, pero si se reabre, entonces significa que no hubo suerte y que hay que intentar otra cosa, incluso con el método de prueba y error, más una dosis de Fé (o sea, "ojalá que funcione").
  2. Con el tiempo los usuarios se cansan de reportar errores debido al desgaste, y entonces disminuyen las incidencias (las reportadas, no las reales), dando la señal aparente de que las cosas mejoran, cuando es todo lo contrario (nuevamente, favoreciendo las estadísticas)
De esta metodología solo puede esperarse una cosa: El Big Bang . Porque tarde o temprano ocurrirá y se irá todo al traste.

El sistema realmente es bastante perverso y las responsabilidades están repartidas entre todos los involucrados, desde los que piden cosas imposibles o innecesarias en tiempos ilusorios hasta los que debieran velar por la calidad de la solución y de la arquitectura de las aplicaciones, pasando por quienes deben gestionar todo el proceso.

Lamentablemente muchos son presa de esta metodología y aunque tengan buena voluntad, no tienen forma de luchas contra el Sistema, ya que ponerle solución implicaría hacer cambios que no todos están dispuestos a hacer. Al final la excusa de que "siempre se hizo así" muchas veces gana.

Cualquier parecido con la realidad es pura casualidad...


Seguramente alguno tendrá alguna anécdota para comentar al respecto.

Hasta la próxima!


jueves, enero 25, 2018

Visual FoxPro 9: Cómo arreglar ciertos tipos de corrupción en librerías VCX (_Memberdata)

En Visual FoxPro las librerías pueden funcionar con ciertos tipos de corrupción sin que nos demos cuenta y sin errores visibles o funcionales, pero cuando se trabaja con Control de Código fuente y se usan las vistas de texto, como la generada por FoxBin2Prg, a veces estos errores se hacen evidentes y siempre es mejor solucionarlos.

En este artículo veremos el caso de _Memberdata y cómo arreglarlo.



_Memberdata

_Memberdata es una propiedad que guarda la capitalización de las propiedades y métodos creados. Por defecto VFP crea todas las propiedades y métodos en minúsculas, pero con la propiedad _Memberdata VFP puede recordar la capitalización que le demos a la propiedad (Ver más información en la ayuda de VFP o en la web de Microsoft sobre MemberData Extensibility)

Por ejemplo, si creamos la propiedad "ValorMaximo" con el PEM Editor (de VFPx), la propiedad _Memberdada tendrá información con esta estructura:

<VFPData>
   <memberdata name="valormaximo" display="ValorMaximo"/>
</VFPData>


Donde:
  • name contiene el nombre original en minúsculas
  • type (opcionalmente) contiene el tipo de elemento ("Property" o "Method" habitualmente)
  • display contiene el nombre capitalizado a mostrar

Propiedad "ValorMaximo" creada con el PEM Editor


A medida que se van agregando propiedades capitalizadas, se irán agregando también elementos <memberdata name="xx" display="Xx">, y llegado un momento dado este campo puede llegar a ser bastante largo (puede tener hasta unos 8 KiB de longitud)

Este es un ejemplo de propiedad _Memberdata corrupta, visto con el Notepad++ desde la vista texto generada por FoxBin2Prg de la librería foxcharts.vcx en GitHub:



Pueden observarse algunos problemas evidentes:

  1. VFPData aparece varias veces, cuando solo debería aparecer 2 veces
  2. Siendo un miembro codificado en XML, debería tener un tag <VFPData> de inicio y un tag </VFPData> final, el cual no se ve
  3. El tag <VFPData> de inicio está anidado en sí mismo varias veces
Bueno, sabemos que esto está mal y queremos solucionarlo, ¿cómo se puede verificar la lista de propiedades que debería ir? Esa parte es fácil, solamente hay que echar un vistazo en la cabecera VC2 de la clase para ver qué propiedades y métodos se han definido:

*<DefinedPropArrayMethod>
    *m: caption_assign
    *m: reset        && Resets the legend GDI+ objects
    *m: rotation_assign
    *m: _drawstring
    *m: _setup
    *m: _updatemeasures
    *m: _value_assign
    *p: backcoloralpha
    *p: forecoloralpha
    *p: format        && Specifies the input and ...
    *p: format2
    *p: isparent
    *p: ogfx
    *p: rotationcenter
    *p: _forceformat
    *p: _height
    *p: _initialized
    *p: _memberdata        && XML Metadata ...
    *p: _obrush
    *p: _ofont
    *p: _orectangle
    *p: _ostringformat
    *p: _transfcaption
    *p: _value
    *p: _vartype
    *p: _width
*</DefinedPropArrayMethod>



Mirando nuevamente la propiedad _Memberdata y su contenido, puede verse un patrón de repetición de varias propiedades, donde básicamente se repite esta parte:

_memberdata = <VFPData>
   <memberdata name="autosize" ... display="AutoSize"/>
   <memberdata name="whatsthishelpid" ... display="WhatsThisHelpID"/>
   <memberdata name="_setup" ...display="_Setup"/>
   <memberdata name="forecoloralpha" ... display="ForeColorAlpha"/>
   <memberdata name="backcoloralpha" ... display="BackColorAlpha"/>
   <memberdata name="width" ... display="Width"/>
   <memberdata name="oledragpicture" ... display="OLEDragPicture"/>

   ...
</VFPData>        && XML Metadata for customizable properties
con lo que recortando cuidadosamente el resto de repeticiones hasta el tag de finalización </VFPData>, quedaría resuelta esta parte.

Nota: Revisando esta librería encontré que tiene más secciones <VFPData> con problemas más adelante, con lo que una vez detectado el problema siempre es conveniente buscar y revisar todas las estructuras <VFPData> para asegurarse de que están correctas.


Puede pasar que alguna de las propiedades descriptas en los miembros <memberdata> esté incompleta o cortada, por ejemplo podría contener solamente la parte del "name" pero no la parte del "display".

Nuevamente, conociendo que la estructura mínima de un miembro debe contener el name y el display, simplemente se puede crear manualmente la propiedad display y ponerle un valor que seguramente va a ser bastante obvio: el nombre de la propiedad capitalizada que querramos que se muestre en el IDE de VFP.



Resumen


Una vez resueltos todos los problemas, se regenera el binario desde esta vista texto (click-derecho sobre el archivo VC2, elegir "Enviar a" -> FoxBin2Prg)

Como se ve, realmente no es difícil solucionar varios de estos problemas, pero sí es necesario dedicar un rato para analizar el problema, conocer qué es lo que estamos modificando, cuál es la estructura correcta e implementar la solución.


Hasta la próxima! :D

sábado, enero 13, 2018

PlasticSCM: Cambiar la ubicación del Repositorio

(Publicado originalmente por Carton Jeston en el foro Google de la Comunidad Visual FoxPro)
https://groups.google.com/d/msg/publicesvfoxpro/faUPGOBsdBs/kfg7jBtmBAAJ

---

Después de instalar plasticscm en su carpeta por defecto (c:\Program Files\PlasticSCM5\) los repositorios se guardan dentro de la subcarpeta SERVER.  No me parece una gran idea tener datos importantes en la misma partición de windows y necesito, por motivos de seguridad y para facilitar el backup, que estén separados y en otra ubicación.

Lo primero es salir del plasticscm y asegurar que no hay ningún servicio dependiente o archivo abierto y hacer una copia de seguridad de toda la carpeta PlasticSCM5 por si fallara algo.

Para este ejemplo, teniendo una unidad/particion D: para los datos importantes, creare una carpeta llamada PLASTIC en el disco D: (D:\PLASTIC) que es la nueva ubicación donde se guardaran los repositorios. Recomiendo usar siempre minúsculas aunque Windows no se vea afectado por ello.

Dentro de la subcarpeta SERVER hay un archivo de texto llamado DB.CONF, que si se instala por defecto con la base de datos SQLITE deberá tener esta información:


<DbConfig>
 
<ProviderName>sqlite</ProviderName>
 
<ConnectionString>Data Source={0};Synchronous=FULL;Journal Mode=WAL;Pooling=true</ConnectionString>
 
<DatabasePath></DatabasePath>
</DbConfig>

Y entre <DatabasePath>d:\plastic</DatabasePath> insertamos la ubicación de la carpeta que hemos creado antes, recordando que mejor en minúsculas, quedando así:



<DbConfig>
 
<ProviderName>sqlite</ProviderName>
 
<ConnectionString>Data Source={0};Synchronous=FULL;Journal Mode=WAL;Pooling=true</ConnectionString>
 
<DatabasePath>d:\plastic</DatabasePath>
</DbConfig>

Ahora guardamos los cambios el archivo que hemos editado DB.CONF.

Como hemos observado anteriormente, las bases de datos que empleaba plasticscm era SQLITE, así que buscamos en la misma carpeta SERVER todos los archivos con extensión .SQLITE y tendrás algo así:

repositories.plastic.sqlite
rep_1.sqlite
rep_2.sqlite
etc.


Ahora hay que moverlos todos a la nueva carpeta que creamos (D:\PLASTIC) y si todo ha ido bien, al abrir plasticscm apuntara a los repositorios guardados en esta ubicación.

Ya está.

En mi caso, cuando hago una versión nueva final de mi aplicación, hago la copia del workspace (donde esta nuestro proyecto, formularios, prg,etc) que tengo en esa unidad de datos y ahora ademas hago la copia de los repositorios para salvaguardar también la base de datos de los cambios de la versión de la aplicación. No hay que olvidar que un mal paso, un virus o una rotura de disco duro y siempre hay que tener copia de seguridad.



¿Como parar/reanudar el servicio de plastic para hacer un backup/restore de los repositorios?

Como he comentado arriba, conviene para el servicio de plasticscm antes de hacer un backup y sobre todo, al restaurar copiando nuestros repositorios puede dar errores.

Te darás cuenta que en la carpeta de los repositorios en algún momento habrán dos archivos con el nombre de un repositorio y con la extensión .sqlite-shm y .sqlite-wal y es porque plasticscm esta haciendo algún trabajo en segundo plano.

Para evitar conflictos, lo mejor es parar el servicio y que termine lo que esta haciendo y después hacer nuestras copias de los repositorios sin ningún problema.

Pulsar Ctrl+Alt+Supr y elegir la opción "Iniciar administrador de tareas". Pulsar en la pestaña Servicios, buscar el nombre PLASTIC SERVER 5 y pulsas con el botón derecho del ratón. Ahora elegir Detener servicio, hacer nuestras copias o restaurarlas en cuanto desaparezcan los dos archivos mencionados arriba y al terminar, botón derecho de nuevo sobre el servicio y elegir Iniciar servicio.

También puedes acceder a los Servicios a través del Panel de control de Windows, Herramientas administrativas y elegir Servicios.

Otro metodo alternativo mediante la consola de comandos del sistema (ejecutar-cmd) o automatizar mediante un archivo BAT o similar o bien acceso directo:

net start "plastic server 5"    >>> inicia el servicio     
                                                            
net stop  "plastic server 5"    >>> detiene el servicio    

[N.del E.] o también:

sc \\localhost start "plastic server 5"                      
                                                             
sc \\localhost stop  "plastic server 5"                      




Particularmente me gusta mucho este método por su automatización y porque te indica cuando ha terminado la operación correctamente y seguro para un proceso desatendido. Tener en cuenta de probarlo por primera vez manualmente y ver que el nombre del servicio no ha cambiado, actualmente es la versión plasticSCM 5.



Número del archivo de base de datos de Plastic

Para poder saber qué workspace tenemos en qué repositorio (BDD), debemos usar el comando cm desde la consola de Windows, con este parámetro:


cm lrep --format="TABLE"                                      

Que en mi caso deja una salida como esta:

 1 default localhost:8087                                     
 2 dvcs_vfp9 localhost:8087                                   
 5 foxpro_diff_merge localhost:8087                           
 6 filename_caps localhost:8087                               


Donde la primera columna contiene el número de repositorio, la segunda el nombre del workspace y la tercera la máquina:puerto donde apunta.

Si se está usando la nomenclatura de repositorio por defecto ( osea que no se ha cambiado) y se usa SQLite, entonces  el nombre del repositorio es de la forma:

rep_NN.plastic.sqlite

Y aplicando el número obtenido a la nomenclatura, se puede ver que el nombre de BDD del repositorio que contiene el workspace  dvcs_vfp9, será:

rep_2.plastic.sqlite


Nota: Para que el comando cm funcione sin tener que indicar la ruta cada vez, es buena idea agregar la ruta "c:\Program Files\PlasticSCM5\client" al PATH de Windows.



Hasta la próxima! :D

Artículos relacionados:
PlasticSCM: Opciones de conectividad, transporte del código fuente y backup
PlasticSCM: Cómo configurar la replicación de repositorios Plastic locales y remotos