intro perso

[Marc SCHAEFER]

On Mon, 2 Apr 2001, Erik Rossen wrote:

> Personnellement, je préfère qu'on commence petit et pratique,
> c'est-à-dire, essayer de programmer des modules DTA et OPAE qui
> fonctionnent avec GnuCash ainsi que GULLCompta (éventuellement).  Ça me

Je ne connais pas ces logiciels, mais je seconde l'idée de faire
rapidement un petit prototype qui fait juste l'essentiel. La définition
d'essentiel sera certainement sujette à conflits :).

Pour moi c'est:

   Base de donnée PostgreSQL remplie par un front-end quelconque (Perl,
   psql, Star Office, pgaccess), convertie dans les deux sens au format
   OPAE ou OTA

Pourquoi les deux sens ?

   1. regression testing automatique à chaque release

   2. l'autre application, la prise en compte des paiements utilise,
      à ma connaissance, un format symétrique. Et de plus l'excellent
      Félix Hauri s'y connaît.

Pourquoi une base de données, en particulier PostgreSQL ?

   La structure SQL ainsi que l'utilisation de contraintes d'intégrité
   permet de diminuer la charge de travail et la complexité du code.
   (p.ex: il est envisageable de faire le test d'intégrité des ``numéros
    complémentaires'' directement en PL/SQL, comme sécurité
    `last-niveau').

   L'installation et l'administration sont nulles (si le logiciel s'occupe
   de la sauvegarde si nécessaire)

      # apt-get install postgresql
      postgres% createuser schaefer
      schaefer% createdb paiements && ./create_db.pl paiements
      schaefer% cp odbc.sample .odbc.ini
      schaefer% ./Office52/soffice odbc:paiements # simplifié
      schaefer% ./convert_paiements_to_dta.pl paiements > paiements.dta
      schaefer% destroydb paiements && createdb paiements && \
                ./create_db.pl paiements
      schaefer% ./dta_to_paiements.pl paiements < paiements.dta

Pourquoi ainsi ?

   On se concentre *uniquement* sur le point le plus important, la
   conversion d'information. On laisse les problèmes d'interface à
   WWW ou un client SQL/ODBC. On laisse les problèmes de format à
   une base de données. Rien n'empêche ensuite de remplacer des
   composants vus comme inefficaces pour certaines mises en oeuvre.

   On peut avoir plusieurs bases de données pour différentes applications.

> Certains (Salut, Gilbert!) pensent qu'il vaut mieux qu'on fait un bon
> plan, très structuré, avant qu'on commence.  Mais des autres projets comme

Personnellement, pour des projets au boulot (ceux pour lesquels on est
payé, ceux pour lesquels on a quelques mois à 100%), j'insiste beaucoup
sur ces aspects. Ca bouffe d'ailleurs en général une grande partie du
temps, mais bon pour ce genre de projets on a le temps (sisi).

D'ailleurs dans certains cas le travail à plusieurs n'est pas possible
sans une grande structuration.

Mais dans le cas d'un logiciel développé sur Internet avec des personnes
qui n'ont pas les mêmes intérêts, les mêmes disponibilités, etc,
l'approche minimaliste mais qui fait avancer le schmilblick me semble
meilleure, en particulier si ensuite on fait appel à un nombre élevés de
testeurs, de documenteurs, et que l'on accepte le fait qu'un grand nombre
des versions seront prêtes-à-poubelliser.

En tous cas la plupart des projets open source qui sont très bien
structurés sont soit le résultat de l'ouverture d'un logiciel
propriétaire, sur lequel finalement que des personnes issues des
entreprises concernées travaillent (Mozilla, Open Office), soit finissent
mal. Soit les deux. D'ailleurs Mozilla à mon avis va finir mal ...

> générale qui arrive à ces projets qui sont tous blah-blah et pas de code.

et j'ai une extrêmement mauvaise impression, en ce moment, sur le projet
Open Office. A lire leurs mailing-lists, on a l'impression qu'ils ont plus
envie de parler de marketing que de corrections des bugs qui restent ou de
simplifications. Faut dire que OO est un projet *gigantesque*.

> Finalement, je crois que les deux choses vont passer au même temps - ceux
> qui veulent coder va commencer et ceux qui sont capable de planifier ce
> projet vont faire ça.  Tant mieux.

Je te rejoins: qu'une personne qui a *besoin* de faire ses paiements
électroniquement commence à pondre du code, qu'il soit moche ou pas n'a
aucune importance, que cela soit en SQL ou avec des structures en C, qu'il
fasse les démarches avec la Poste pour obtenir le droit de faire des
essais, et je suis persuadé que l'on aidera cette personne, en testant, en
améliorant, etc. 

En parallèle, ceux qui se sentent une âme de concepteurs peuvent nous
pondre une spécification, et j'espère sincèrement qu'à l'aide de ces deux
courants nous arriveront à un bon résultat.