Classic sur les Macs modernes

On Mon, 28 Aug 2006 21:54:24 +0200, pmanet@invivo.edu (manet) wrote:

si ça tournait sous 4D, pas de raison qu'on ne puisse pas le refaire
sous FMP (sauf si beaucoup de modules proprio en C rajoutés et pas
documentés), ce qui leur coutera nettement moins cher et aura
certainement plus de fonctionnalité qu'une sqlonnerie.
J'en suis beaucoup moins sûre que toi... Je connais des Sqlonneries

absolument remarquables. Et qui offrent, vues de ma fenêtre, un
avantage décisif : pas besoin de client dédié.

Et refaire un
truc en SQL leur coutera certainement bien plus cher que de le migrer
sous une version récente de 4D ;
Si tu compares les tarifs de gens sérieux sur 4D et sérieux sur MySql,

j'en suis moins sûre aussi... Et après longue discussion hier avec un
pote ayant bossé dans une SSII spécialisée 4D jusque y a peu, le
chantier serait vaste. Beaucoup plus que je ne pouvais imaginer.

je ne comprends pas ton raisonnement, à
moins que tu ne te laisse emporter par une haine particulière de 4D.
Oui, je déteste 4D. Et pourtant j'ai fait des applis dessus à son

heure de gloire, et je dois reconnaître qu'avec un peu d'habitude et
en sachant contourner les bugs, on pouvait faire des trucs très sexe.
Mais se reposer en 2006 sur un produit aussi peu diffusé, confidentiel
et propriétaire, ça dépasse mon entendement. Si je suis ce dossier et
si il évolue, 4D dégagera, c'est clair. FM me gênerait moins. Un peu,
mais moins.
--
Nina

Nina Popravka <Nina@nospam> wrote:

J'en suis beaucoup moins sûre que toi... Je connais des Sqlonneries
absolument remarquables.

vite, des noms...

Et qui offrent, vues de ma fenêtre, un
avantage décisif : pas besoin de client dédié.

déjà, c'est tout vu. Une appli à laquelle on accède par un navigateur
sera forcement une daube. C'est utilisable si on entre quelques données
par semaine, mais 8 heures par jour tous les jours, c'est horrible. La
baisse de productivité entrainée par ce genre d'interface doit revenir
terriblement cher.

En revanche, je comprends que ça simplifie la vie du gestionnaire de
parc informatique ; mais il n'est pas là pour ça (il est meme plutot là
pour s'emm... techniquement le plus pssible, afin que l'utilisateur ait
les meilleures fonctionnalités disponibles), et ce ne doit surtout pas
etre ce genre d'argument qui oriente la décision.

Et refaire un
truc en SQL leur coutera certainement bien plus cher que de le migrer
sous une version récente de 4D ;
Si tu compares les tarifs de gens sérieux sur 4D et sérieux sur MySql,

j'en suis moins sûre aussi... Et après longue discussion hier avec un
pote ayant bossé dans une SSII spécialisée 4D jusque y a peu, le
chantier serait vaste. Beaucoup plus que je ne pouvais imaginer.

justement ; si c'est compliqué à adapter sous 4D, c'est que ce n'est pas
un truc simple. Et refaire un truc compliqué en SQL en partant de rien
avec un nouveau dev auquel il faut tout re expliquer, c'est forcement :
- encore plus long
- encore plus difficile
- plein d'aller retours chez le client, installs, reinstall, tests et
debuggages
- et donc TRES cher, à la fois en prestations informatiques et en temps
perdu par le client lui-meme. Sans compter la nécessité de récupérer 10
ans de données... miam les délices des transformations de dates et
d'heure, les écrans dessinées top moumoute, les listings qui tiennent
juste sur l'imprimante, etc... tout des trucs vachement sympa à faire
sur une base SQL...

Oui, je déteste 4D.

moi aussi, mais si quelqu'un est habitué aux prestations d'une base 4D,
il aura du mal à se faire à une sqlonnerie.

Mais se reposer en 2006 sur un produit aussi peu diffusé, confidentiel
et propriétaire,

propriétaire, ça veut dire quoi ? quelles sont les conséquences ? le dev
que tu va lui proposer, il sera quoi, vu du client ? du moment que tu as
accès au mot de passe maitre de l'appli 4D, le fait que le SGDB soit
propriétaire n'est pas un vrai problème.Inversement, sous un machin SQL,
on peut aussi faire du code propriétaire et verrouiller l'appli. et si
c'est par aapport au prix des licences, en milieux professionnel, le
cout de 4D est vraiment une rigolade.

Je ne comprends absolument pas cette regression qui se dessine
actuellemt. Proposer du SQL a des petites orga de 10 utilisateurs...
c'est vraiment un truc d'informaticien qui ne regarde le monde que par
le bout de sa lorgnette ; on revient aux années 70.

On avait eu le cas pour le WYSIWYG, la souris et les icones ; tous les
informaticiens étaient morts de rire quand le mac est sorti. Il a bien
fallu qu'ils admettent que c'etait une révolution copernicienne.

Les bases de données intégrées sont apparue peu après, avec le moteur,
les utilitaires, le générateur de frontal et le requeteur dans la meme
boite. Revenir au SGDB désintégré, c'est proposer le retour à l'age de
pierre (et surtout, les emm.. assurés) aux utilisateurs. Le problème est
que comme c'est quand meme un peu plus compliqué de faire une base de
donnée que d'utiliser word, les informaticiens gardent la main sur les
sépcifications des systèmes et les décideurs la bouclent par ignorance ;
ça peut changer...

FMP RuLeZ


--
Philippe Manet

manet <pmanet@invivo.edu> wrote:

Nina Popravka <Nina@nospam> wrote:

En ce qui me concerne, il est totalement hors de question de faire
réécrire du 4D. Soit ça reste en l'état, soit ils migrent vers une
solution standard, genre MySql.

Puisqu'ils n'ont qu'une 10aine de postes, on dit pouvoir leur trouver au
fur et à mesure des mac minis d'occase qui feront l'affaire (ou des g4
?).
d'un autre côté, c'est également du reculer pour mieux sauter, car tôt

ou tard, on ne trouvera plus de machines PPC, ou alors complètement
obsolètes ...

--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr

On Tue, 29 Aug 2006 00:16:03 +0200, pmanet@invivo.edu (manet) wrote:

J'en suis beaucoup moins sûre que toi... Je connais des Sqlonneries
absolument remarquables.
vite, des noms...

Récemment un CRM maison absolument ébouriffant croisé au hasard chez

un prospect. J'étais scotchée. Simple, efficient, intelligent. J'étais
tellement épatée que j'ai interviewé les 10 lusers tous ravis, et j'ai
décortiqué les fonctionnalités du machin pendant 2 heures.
J'étais d'autant plus sensibilisée que je tentais de former d'autres
lusers ailleurs sur un autre CRM commercial (et 4D mais j'y suis pour
rien...) dont perso, je l'avoue, j'ai tjs du mal à me retrouver dans
le bordel de l'interface.

Une appli à laquelle on accède par un navigateur
sera forcement une daube. C'est utilisable si on entre quelques données
par semaine, mais 8 heures par jour tous les jours, c'est horrible. La
baisse de productivité entrainée par ce genre d'interface doit revenir
terriblement cher.
De quoi où quand pourquoi en quel honneur ? Pour faire de la saisie en

liste d'annuaires, certes, pour autre chose je ne vois aucune raison.

En revanche, je comprends que ça simplifie la vie du gestionnaire de
parc informatique ; mais il n'est pas là pour ça (il est meme plutot là
pour s'emm... techniquement le plus pssible, afin que l'utilisateur ait
les meilleures fonctionnalités disponibles)
Techniquement, je me bat les ovaires d'installer un navigateur, un

client 4D ou FM, et n'importe quelle source pouvant être consultée par
iceux. C'est un truc technique sans aucun intérêt, limite boulot d'OS,
si le développeur a bien fait son taf.

justement ; si c'est compliqué à adapter sous 4D, c'est que ce n'est pas
un truc simple. Et refaire un truc compliqué en SQL en partant de rien
avec un nouveau dev auquel il faut tout re expliquer
Y en a quand même qui ne sont pas débiles et capables de regarder

l'existant, hein...

les écrans dessinées top moumoute, les listings qui tiennent
juste sur l'imprimante, etc... tout des trucs vachement sympa à faire
sur une base SQL...
Même sous 4D, tout sera à refaire, semble-t-il, donc...

propriétaire, ça veut dire quoi ? quelles sont les conséquences ?
Un vague espoir de pérennité et de stabilité du moteur. Et de la

possibilité de trouver facilement des gens compétents et dispos.

Je ne comprends absolument pas cette regression qui se dessine
actuellemt. Proposer du SQL a des petites orga de 10 utilisateurs...
c'est vraiment un truc d'informaticien qui ne regarde le monde que par
le bout de sa lorgnette ; on revient aux années 70.
L'interface HTML était courante dans les années 70???

SQL n'a rien de dramatique, la preuve même moi, je sais configurer un
SQL server et poser des queries.

FMP RuLeZ
Chacun sa chapelle.

Moi je m'en tape, de toute manière je ne développe pas, je n'ai qu'une
chose à vendre : pas d'emmerdes client heureux et avenir ouvert.
--
Nina

manet <pmanet@invivo.edu> wrote:

- et donc TRES cher, à la fois en prestations informatiques et en temps
perdu par le client lui-meme. Sans compter la nécessité de récupérer 10
ans de données... miam les délices des transformations de dates et
d'heure, les écrans dessinées top moumoute, les listings qui tiennent
juste sur l'imprimante, etc... tout des trucs vachement sympa à faire
sur une base SQL...

La base SQL n'a que faire des écrans dessinés top moumoutes et des
listings qui tiennent juste sur l'imprimante, c'est le frontal, quel
qu'il soit qui gère ça, la base stocke et accède ce qui lui est demandé
par un frontal.

Et quand je vois les merdes pondues en 4D avec une ergonomie proche du
playskool (oooohhhh les gros boutons sans équivalent-clavier...
ooooooooohhhhhh les 25 écrans pour saisir 4 données....) parce que le
dév n'est pas forcément un ergonome (bon, ok, il y a eu du beau fait en
FMP et en 4D mais pour combien de truc affreux !), je me dis que ça ne
peut pas être pire en client web.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.

Nina Popravka <Nina@nospam> wrote:

Ben le client, il est pas dans la mouise, avec ses antiquités...
:-(((((

Le client, s'il veut un G5 pas trop vieux, il a qu'a me conctater :-)

--
Jacques

Laurent Pertois <laurent.pertois@alussinan.org> wrote:

manet <pmanet@invivo.edu> wrote:

- et donc TRES cher, à la fois en prestations informatiques et en temps
perdu par le client lui-meme. Sans compter la nécessité de récupérer 10
ans de données... miam les délices des transformations de dates et
d'heure, les écrans dessinées top moumoute, les listings qui tiennent
juste sur l'imprimante, etc... tout des trucs vachement sympa à faire
sur une base SQL...

La base SQL n'a que faire des écrans dessinés top moumoutes et des
listings qui tiennent juste sur l'imprimante, c'est le frontal, quel
qu'il soit qui gère ça, la base stocke et accède ce qui lui est demandé
par un frontal.

Oui mais bon tu présumes que c'est bien programmé :)

FiLH

--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org

manet <pmanet@invivo.edu> wrote:

justement ; si c'est compliqué à adapter sous 4D, c'est que ce n'est pas
un truc simple.

Ou que justement c'est mal branlé et ça demande une refonte complète
pour réorganiser ça proprement.

Les vieux programmes qui vieillissent en accumulant les verrues ne
demandent jamais mieux que d'être réécrit proprement. C'est une tâche
parfois ingrate, que beaucoup - comme toi - redoutent d'envisager (avec
les mêmes arguments) mais qui au final est souvent intéressante. En
effet avec le temps on a affiné les fonctionnalité et on peut enfin en
faire la synthèse et bien analyser le truc. Un truc qui est bien c'est
qu'on a des spécifications fonctionnelles assez pratiques : l'existant.
On sait que telle opération doit faire telle chose.

Et refaire un truc compliqué en SQL en partant de rien
avec un nouveau dev auquel il faut tout re expliquer, c'est forcement :
- encore plus long

Pas forcément. Tout dépend de la qualité du code existant, et quand on
voit comment on programmait à une époque... (ah la joie de rechercher
toutes les occurences de certain code dupliqué 256 fois dans 56
programmes mais pas cherchable automatiquement parce qu'il y a trois
caractères qui changent).

- encore plus difficile

Pas forcément non plus. pour les mêmes raison.

- plein d'aller retours chez le client, installs, reinstall, tests et
debuggages

Ça...

- et donc TRES cher, à la fois en prestations informatiques et en temps
perdu par le client lui-meme. S

Ah... le temps perdu a court terme est souvent du temps gagné à long
terme.... c'est une visiion que l'entreprise contemporaine a souvent du
mal à avoir, surtout dans l'informatique. Au résultat on ne peut que
constater globalement que le niveau des softs est catastrophique.


FiLH

--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org

On Tue, 29 Aug 2006 07:37:15 +0200, filh@filh.orgie (FiLH) wrote:

justement ; si c'est compliqué à adapter sous 4D, c'est que ce n'est pas
un truc simple.
Ou que justement c'est mal branlé et ça demande une refonte complète

pour réorganiser ça proprement.
En l'occurence, c'est même pas ça, c'est simplement 4D qui a tellement

changé qu'il ne peut pas relire une base 6.5.
--
Nina

FiLH <filh@filh.orgie> wrote:

Oui mais bon tu présumes que c'est bien programmé :)

Evidemment, mais ça n'est pas impossible, contrairement à ce que pense
Philippe, mais c'est pareil pour n'importe quelle appli, l'interface
utilisateur, quelle que soit le frontal utilisé. On peut faire une
interface merdique en n'importe quoi.

--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.