[ASPL Fact devel] Un error y comentarios.

Jesús Martínez jamarcer at inicia.es
Thu Jan 16 09:40:41 CET 2003


Hola:

Bueno, mis primeros "comentarios". Como siempre digo, lo que expongo no
es la verdad ni pretende serlo (salvo casos muy excepcionales ;) ). Así
que, por favor, tomad mis comentarios en su medida. Y si me equivoco, tiradme
de las orejas ;).

Lo primero es un "error": ayer me bajé mediante cvs anónimo el código. Procedí
a compilarlo, y tras algunas dificultades (que luego explicaré) y al llegar
al último paso, la compilación de aspl-fact falló diciendo que no tenía
el /usr/.../install.sh que traen las herramientas de "autocompilación".
¡GLUPS!
Bueno, al grano, modifiqué 1 (un) fichero y funcionó:
en <path_a_directorio_de_instalación>/aspl-fact/aspl-fact/configure.in
donde pone
AC_INIT([aspl-fact], [ML1], [http://bugzilla.aspl.es])
puse
AC_INIT(src/main.c).
No lo considero un bug ;), así que lo pongo en la lista. [Por cierto, si
quereis que lo ponga en el bugzilla, lo hago. Y así practico ;) ].

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Comentarios.
------------
Comentarios a la compilación:

* He llegado al final de la compilación porque he programado alguna vez
en el entorno gnome. Para una persona "sin esos conocimientos", la compilación
con éxito es imposible. Si se pretende recibir ayuda [bueno, si no os molesta
cambiare el "se" por un "nos"], si pretendemos recibir ayuda deberíamos
buscar la forma de optimizar este proceso.

* Y deberíamos avisar (por ejemplo, en la página de descargas) que se necesita
una librería externa y poner el enlace para su descarga. Yo no conocía loadrunner
y pensé que era parte del desarrollo (por lo de libcoyote).

* Supongo que ya lo tendréis hablado: ¿no se podría poner el codigo y/o
los ejecutables en paquetes (deb, rpm, tarball,...)? Para mucha gente es
mas fácil hacer un apt-get o rpm -i que todo el proceso de compilación.
A un futuro empresario que utilice la aplicación le interesará eso: una
instalación rápida y sencilla, del estilo "./setup" y a rular ;).

Comentarios a la configuración:

* Incluir en el README principal (o un documento específico) el usuario
(aspl), su clave (prueba), la máquina (localhost) y el puerto (55000) por
"defecto". Los datos existen pero están muy repartidos: el par usuario/clave
aparece en la web, la máquina la supuse y para el puerto con el netscan
o en el código del programa que prueba el servidor.

* ¿Podrían aparecer esos valores en el wizard y en la pantalla de configuración
por defecto, según se abre?

Comentarios a la ejecución:

* Se puede comentar (en el README o documento de instalación) las opciones
básicas del servidor: en especial como se selecciona el puerto (si se puede
;) , que no he entrado en el código y puede que esté hablando por hablar).

* Me ha encantado la "presentación" (el look): muy profesional. Porque me
leí el hito y sabía lo que estaba ejecutando, si no me decepciono por "lo
poco que sale" ;). He tenido la "sensación" de estar delante de una aplicación
seria [no sé si os ha pasado alguna vez].

* En una configuración gráfica de 1024x786 (y mayores) la letra pequeña
del wizard de configuración no se lee bien (o no se lee).

* En la pantalla de login me "falta" un botón/opción para salir de una forma
"limpia" [sin tener que cerrar la aplicación con los botones del marco].
Por ejemplo, el botón de Configuración lo más a la izquierda y los botones
de Entrar y Cerrar lo más a la derecha.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Más sobre lo dicho. Se me ocurre que puede ser una buena idea ir escribiendo
un "Manual de Usuario" que evolucione con la aplicación. Para este hito
que explique los "defectos" que he ido remarcando: cómo se obtiene, librerías
necesarias, como se compila, como se instala, cómo se ejecuta, ...

¿Existe un grupo de pruebas? No sé si existe. En mi entorno de trabajo se
dan dos o más niveles de pruebas:
* Pruebas unitarias: las que hace el equipo de programación.
* Pruebas de sistema: un equipo "ajeno" al de desarrollo y a partir de un
plan de pruebas comprueba "toda" la aplicación: elemento a elemento, y como
sistema.
* Pruebas de integración: un tercer equipo comprueba que la aplicación se
"integra bien" con el software existente en producción.
[Nota };) : los equipos pueden estar formados por las mismas personas, por
eso de la "economía de recursos"]

El último paso, en el software libre, se puede integrar en la instalación
de la aplicación. Pero los dos primero darían una gran estabilidad a la
aplicación creada.

Presento esto porque no lo he visto reflejado en los documentos, donde sí
aparece reflejadas las pruebas unitarias.

Otra cosa: sobre los documentos. ¿Está previsto un documento de análisis?
Lo pregunto porque es "mala idea" que aparezcan las estructuras de datos
en las especificaciones de requisitos (a partir de ahora ER). Siempre es
buena idea tener una ER estable (si hay que cambiar algo se abre una nueva
rama), y los datos y sus estructuras son de lo más evolutivo de todo el
desarrollo. Pero es sólo una idea ;).

Bueno, creo que he escrito mucho para ser la primera vez. Vamos a descansar
;).


Un saludo
Jesús Martínez

-------------------------------------------------
ADSL Tiscali -  http://adsl.tiscali.es
el más completo y competitivo ¡por sólo 38.95 €!
Y además, llama GRATIS desde tu PC.
-------------------------------------------------







More information about the ASPL-Fact-devel mailing list