Classic sur les Macs modernes

pmanet

30/08/2006 à 00:03

Laurent Pertois wrote:

Evidemment, mais ça n'est pas impossible,

ah, zut, il me manque tous les messages intermédiaires ; orange wanamou
a loupé son feeding ? j'imagine que tu dis qu'on peut théoriquement
sortir des trucs potables avec MySQL.

j'ai perdu depuis longtemps l'habitude de regarder ce qui est
théoriquement possible ou impossible. Je regarde ce qui existe, ce qu'on
te propose pour de vrai dans la vraie réalité.
Et bien depuis 23 ans que je pratique les bases de données, en
utilisateur, prescripteur ou developpeur, je n'ai jamais vu une
sqlonnerie correcte. C'est un fait.

Le B-a-ba, c'est déjà une interface de saisie un minimum ergonomique. Le
boulot qu'il y a à faire sur une sqlonnerie pour mimer un tant soit peu
ce qui existe sur FMP rend déjà un developpement sur commande
difficilement concevable sur le plan économique. Quand on voit ce qui
t'es usuellement proposé... je me crois encore sur mon Apple II avec CX
200 ! ou GCOS 7 sur un Questar 400...

faire en partant de zéro une interface avec des boutons radios, des
cases à cocher, des menus déroulants, des listes conditionnelles, avec
un contenu modifiable, des explications qui apparaissent quand tu passe
dessus, c'est effectivement faisable. Mais c'est un tel boulot que ce
n'est économiquement envisageable que sur un petit nombre d'écrans, et
donc sur une base simple. Et dans ce cas, pourquoi donc utiliser
l'artillerie lourde d'une base SQL, avec ce que ça implique comme
problème pour la maintenance... ET par la suite, quand il faut modifier
un truc, en rajouter un, quelle galère... et quel cout ! Résultat, ça
donne des bases figées.

Mais l'ergonomie de l'interface ne résume pas la base de donnée, sinon
on a un joli cimetière de donnée, mais ça reste un cimetière. Par BD
correcte, j'entends mieux, càd une base évolutive, dans laquelle un
utilisateur puisse faire des requetes multicritères et des exports sous
des formats variés sans que cela ait été préprogrammé à l'origine. Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein ; que chaque fois que je faisais une exploitation un peu lourde,
je me rendais compte que leurs sorties étaient fausses ; mais je m'en
apercevais parce que j'étais un maniaque, et que j'avais des moyens de
vérification ; résultat, ils corrigeaint, mais il y avait d'autres
problèmes...

Et pourtant, la complexité du truc fait qu'on compare généralement des
machins sous 4D ou FMP faits par des amateurs avec des sqloneries (j'y
intègre Oracle) faites par des pros, qui coutent souvent entre 10 et 100
fois plus chères...

Le mieux serait d'avoir des pros qui acceptent de faire des vraies
bases, avec un modèle de donnée solide et des procédure de maintenance
prévues dès l'origine (c'est souvent le problème de fond des bases
d'amateur), mais avec des bon produits comme 4D ou FMP (et en foutant
définitivement à la poubelle cette saloperie d'Access, qui est le pire
de tous...).
--
Philippe Manet

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

Evidemment, mais ça n'est pas impossible,

ah, zut, il me manque tous les messages intermédiaires ; orange wanamou
a loupé son feeding ? j'imagine que tu dis qu'on peut théoriquement
sortir des trucs potables avec MySQL.

j'ai perdu depuis longtemps l'habitude de regarder ce qui est
théoriquement possible ou impossible. Je regarde ce qui existe, ce qu'on
te propose pour de vrai dans la vraie réalité.
Et bien depuis 23 ans que je pratique les bases de données, en
utilisateur, prescripteur ou developpeur, je n'ai jamais vu une
sqlonnerie correcte. C'est un fait.

Le B-a-ba, c'est déjà une interface de saisie un minimum ergonomique. Le
boulot qu'il y a à faire sur une sqlonnerie pour mimer un tant soit peu
ce qui existe sur FMP rend déjà un developpement sur commande
difficilement concevable sur le plan économique. Quand on voit ce qui
t'es usuellement proposé... je me crois encore sur mon Apple II avec CX
200 ! ou GCOS 7 sur un Questar 400...

faire en partant de zéro une interface avec des boutons radios, des
cases à cocher, des menus déroulants, des listes conditionnelles, avec
un contenu modifiable, des explications qui apparaissent quand tu passe
dessus, c'est effectivement faisable. Mais c'est un tel boulot que ce
n'est économiquement envisageable que sur un petit nombre d'écrans, et
donc sur une base simple. Et dans ce cas, pourquoi donc utiliser
l'artillerie lourde d'une base SQL, avec ce que ça implique comme
problème pour la maintenance... ET par la suite, quand il faut modifier
un truc, en rajouter un, quelle galère... et quel cout ! Résultat, ça
donne des bases figées.

Mais l'ergonomie de l'interface ne résume pas la base de donnée, sinon
on a un joli cimetière de donnée, mais ça reste un cimetière. Par BD
correcte, j'entends mieux, càd une base évolutive, dans laquelle un
utilisateur puisse faire des requetes multicritères et des exports sous
des formats variés sans que cela ait été préprogrammé à l'origine. Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein ; que chaque fois que je faisais une exploitation un peu lourde,
je me rendais compte que leurs sorties étaient fausses ; mais je m'en
apercevais parce que j'étais un maniaque, et que j'avais des moyens de
vérification ; résultat, ils corrigeaint, mais il y avait d'autres
problèmes...

Et pourtant, la complexité du truc fait qu'on compare généralement des
machins sous 4D ou FMP faits par des amateurs avec des sqloneries (j'y
intègre Oracle) faites par des pros, qui coutent souvent entre 10 et 100
fois plus chères...

Le mieux serait d'avoir des pros qui acceptent de faire des vraies
bases, avec un modèle de donnée solide et des procédure de maintenance
prévues dès l'origine (c'est souvent le problème de fond des bases
d'amateur), mais avec des bon produits comme 4D ou FMP (et en foutant
définitivement à la poubelle cette saloperie d'Access, qui est le pire
de tous...).
--
Philippe Manet

Vous avez filtré cet utilisateur ! Consultez son message

Laurent Pertois wrote:

Evidemment, mais ça n'est pas impossible,

ah, zut, il me manque tous les messages intermédiaires ; orange wanamou
a loupé son feeding ? j'imagine que tu dis qu'on peut théoriquement
sortir des trucs potables avec MySQL.

j'ai perdu depuis longtemps l'habitude de regarder ce qui est
théoriquement possible ou impossible. Je regarde ce qui existe, ce qu'on
te propose pour de vrai dans la vraie réalité.
Et bien depuis 23 ans que je pratique les bases de données, en
utilisateur, prescripteur ou developpeur, je n'ai jamais vu une
sqlonnerie correcte. C'est un fait.

Le B-a-ba, c'est déjà une interface de saisie un minimum ergonomique. Le
boulot qu'il y a à faire sur une sqlonnerie pour mimer un tant soit peu
ce qui existe sur FMP rend déjà un developpement sur commande
difficilement concevable sur le plan économique. Quand on voit ce qui
t'es usuellement proposé... je me crois encore sur mon Apple II avec CX
200 ! ou GCOS 7 sur un Questar 400...

faire en partant de zéro une interface avec des boutons radios, des
cases à cocher, des menus déroulants, des listes conditionnelles, avec
un contenu modifiable, des explications qui apparaissent quand tu passe
dessus, c'est effectivement faisable. Mais c'est un tel boulot que ce
n'est économiquement envisageable que sur un petit nombre d'écrans, et
donc sur une base simple. Et dans ce cas, pourquoi donc utiliser
l'artillerie lourde d'une base SQL, avec ce que ça implique comme
problème pour la maintenance... ET par la suite, quand il faut modifier
un truc, en rajouter un, quelle galère... et quel cout ! Résultat, ça
donne des bases figées.

Mais l'ergonomie de l'interface ne résume pas la base de donnée, sinon
on a un joli cimetière de donnée, mais ça reste un cimetière. Par BD
correcte, j'entends mieux, càd une base évolutive, dans laquelle un
utilisateur puisse faire des requetes multicritères et des exports sous
des formats variés sans que cela ait été préprogrammé à l'origine. Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein ; que chaque fois que je faisais une exploitation un peu lourde,
je me rendais compte que leurs sorties étaient fausses ; mais je m'en
apercevais parce que j'étais un maniaque, et que j'avais des moyens de
vérification ; résultat, ils corrigeaint, mais il y avait d'autres
problèmes...

Et pourtant, la complexité du truc fait qu'on compare généralement des
machins sous 4D ou FMP faits par des amateurs avec des sqloneries (j'y
intègre Oracle) faites par des pros, qui coutent souvent entre 10 et 100
fois plus chères...

Le mieux serait d'avoir des pros qui acceptent de faire des vraies
bases, avec un modèle de donnée solide et des procédure de maintenance
prévues dès l'origine (c'est souvent le problème de fond des bases
d'amateur), mais avec des bon produits comme 4D ou FMP (et en foutant
définitivement à la poubelle cette saloperie d'Access, qui est le pire
de tous...).
--
Philippe Manet

laurent.pertois

30/08/2006 à 01:31

manet wrote:

Laurent Pertois wrote:

Evidemment, mais ça n'est pas impossible,

ah, zut, il me manque tous les messages intermédiaires ; orange wanamou
a loupé son feeding ? j'imagine que tu dis qu'on peut théoriquement
sortir des trucs potables avec MySQL.

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout, ce qu'il y a derrière,
c'est kif-kif, la base de données n'y change rien, si ce n'est les
possibilités et je pense que SQL l'emporte sur FMP (que j'adore par
ailleurs).

j'ai perdu depuis longtemps l'habitude de regarder ce qui est
théoriquement possible ou impossible. Je regarde ce qui existe, ce qu'on
te propose pour de vrai dans la vraie réalité.
Et bien depuis 23 ans que je pratique les bases de données, en
utilisateur, prescripteur ou developpeur, je n'ai jamais vu une
sqlonnerie correcte. C'est un fait.

Tu n'as jamais vu de frontend à SQL correct, je nuançais. Après, on peut
faire des requêtes SQL depuis Excel et faire un masque dans cette appli.
On doit même pouvoir faire ça avec FMP, je suis sûr.

Le B-a-ba, c'est déjà une interface de saisie un minimum ergonomique. Le
boulot qu'il y a à faire sur une sqlonnerie pour mimer un tant soit peu
ce qui existe sur FMP rend déjà un developpement sur commande
difficilement concevable sur le plan économique. Quand on voit ce qui
t'es usuellement proposé... je me crois encore sur mon Apple II avec CX
200 ! ou GCOS 7 sur un Questar 400...

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

faire en partant de zéro une interface avec des boutons radios, des
cases à cocher, des menus déroulants, des listes conditionnelles, avec
un contenu modifiable, des explications qui apparaissent quand tu passe
dessus, c'est effectivement faisable. Mais c'est un tel boulot que ce
n'est économiquement envisageable que sur un petit nombre d'écrans, et
donc sur une base simple. Et dans ce cas, pourquoi donc utiliser
l'artillerie lourde d'une base SQL, avec ce que ça implique comme
problème pour la maintenance... ET par la suite, quand il faut modifier
un truc, en rajouter un, quelle galère... et quel cout ! Résultat, ça
donne des bases figées.

Pas forcément, ce dont tu parles, on le fait déjà dans des pages web, tu
dois pouvoir ainsi faire des développements dont les éléments
d'interface vont pouvoir s'adapter à ce que tu fais. Regarde des
développements comme GMail, il y a pourtant une interface complète avec
derrière une base de données et c'est du client web.

Mais l'ergonomie de l'interface ne résume pas la base de donnée, sinon
on a un joli cimetière de donnée, mais ça reste un cimetière. Par BD
correcte, j'entends mieux, càd une base évolutive, dans laquelle un
utilisateur puisse faire des requetes multicritères et des exports sous
des formats variés sans que cela ait été préprogrammé à l'origine.

C'est toujours programmé à l'origine, tu ne pourras jamais exporter en
Excel dans FMP7, c'est arrivé avec la 8, au mieux tu feras de l'export
texte tabulé ou autre truc basique.

Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Et j'ai vu des gens faire tourner des quantités de données monstrueuses
dans Oracle alors qu'un FMP serait mort rien qu'à l'idée d'en avoir
autant. Et ces données n'étaient pas perdues pour autant...

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein ; que chaque fois que je faisais une exploitation un peu lourde,
je me rendais compte que leurs sorties étaient fausses ; mais je m'en
apercevais parce que j'étais un maniaque, et que j'avais des moyens de
vérification ; résultat, ils corrigeaint, mais il y avait d'autres
problèmes...

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

Et pourtant, la complexité du truc fait qu'on compare généralement des
machins sous 4D ou FMP faits par des amateurs avec des sqloneries (j'y
intègre Oracle) faites par des pros, qui coutent souvent entre 10 et 100
fois plus chères...

Franchement, des applis métiers en 4D, j'en ai vu pas mal, le seul
sentiment que j'ai c'est : souvent, c'est lourd, môche, on ajoute des
trucs au fur et à mesure de l'évolution du produit et de la demande des
utilisateurs, ça ne respecte aucune règle d'ergonomie de l'interface et
ça en devient vite une plaie à utiliser. Mais, boum, t'es bloqué dedans
parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

Le mieux serait d'avoir des pros qui acceptent de faire des vraies
bases, avec un modèle de donnée solide et des procédure de maintenance
prévues dès l'origine (c'est souvent le problème de fond des bases
d'amateur), mais avec des bon produits comme 4D ou FMP (et en foutant
définitivement à la poubelle cette saloperie d'Access, qui est le pire
de tous...).

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

PS :

Le lien Google de mon post :

<http://groups.google.com/group/fr.comp.os.mac-os.x/browse_thread/thread
/e122e86edc1b86de/d72dd770b4398f62?lnk=st&q=1hkt78e.1ytlgp2mtg0zqN%25lau
rent.pertois%40alussinan.org&rnum=1&hl=en#d72dd770b4398f62>

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

manet <pmanet@invivo.edu> wrote:

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

Evidemment, mais ça n'est pas impossible,

ah, zut, il me manque tous les messages intermédiaires ; orange wanamou
a loupé son feeding ? j'imagine que tu dis qu'on peut théoriquement
sortir des trucs potables avec MySQL.

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout, ce qu'il y a derrière,
c'est kif-kif, la base de données n'y change rien, si ce n'est les
possibilités et je pense que SQL l'emporte sur FMP (que j'adore par
ailleurs).

j'ai perdu depuis longtemps l'habitude de regarder ce qui est
théoriquement possible ou impossible. Je regarde ce qui existe, ce qu'on
te propose pour de vrai dans la vraie réalité.
Et bien depuis 23 ans que je pratique les bases de données, en
utilisateur, prescripteur ou developpeur, je n'ai jamais vu une
sqlonnerie correcte. C'est un fait.

Tu n'as jamais vu de frontend à SQL correct, je nuançais. Après, on peut
faire des requêtes SQL depuis Excel et faire un masque dans cette appli.
On doit même pouvoir faire ça avec FMP, je suis sûr.

Le B-a-ba, c'est déjà une interface de saisie un minimum ergonomique. Le
boulot qu'il y a à faire sur une sqlonnerie pour mimer un tant soit peu
ce qui existe sur FMP rend déjà un developpement sur commande
difficilement concevable sur le plan économique. Quand on voit ce qui
t'es usuellement proposé... je me crois encore sur mon Apple II avec CX
200 ! ou GCOS 7 sur un Questar 400...

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

faire en partant de zéro une interface avec des boutons radios, des
cases à cocher, des menus déroulants, des listes conditionnelles, avec
un contenu modifiable, des explications qui apparaissent quand tu passe
dessus, c'est effectivement faisable. Mais c'est un tel boulot que ce
n'est économiquement envisageable que sur un petit nombre d'écrans, et
donc sur une base simple. Et dans ce cas, pourquoi donc utiliser
l'artillerie lourde d'une base SQL, avec ce que ça implique comme
problème pour la maintenance... ET par la suite, quand il faut modifier
un truc, en rajouter un, quelle galère... et quel cout ! Résultat, ça
donne des bases figées.

Pas forcément, ce dont tu parles, on le fait déjà dans des pages web, tu
dois pouvoir ainsi faire des développements dont les éléments
d'interface vont pouvoir s'adapter à ce que tu fais. Regarde des
développements comme GMail, il y a pourtant une interface complète avec
derrière une base de données et c'est du client web.

Mais l'ergonomie de l'interface ne résume pas la base de donnée, sinon
on a un joli cimetière de donnée, mais ça reste un cimetière. Par BD
correcte, j'entends mieux, càd une base évolutive, dans laquelle un
utilisateur puisse faire des requetes multicritères et des exports sous
des formats variés sans que cela ait été préprogrammé à l'origine.

C'est toujours programmé à l'origine, tu ne pourras jamais exporter en
Excel dans FMP7, c'est arrivé avec la 8, au mieux tu feras de l'export
texte tabulé ou autre truc basique.

Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Et j'ai vu des gens faire tourner des quantités de données monstrueuses
dans Oracle alors qu'un FMP serait mort rien qu'à l'idée d'en avoir
autant. Et ces données n'étaient pas perdues pour autant...

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein ; que chaque fois que je faisais une exploitation un peu lourde,
je me rendais compte que leurs sorties étaient fausses ; mais je m'en
apercevais parce que j'étais un maniaque, et que j'avais des moyens de
vérification ; résultat, ils corrigeaint, mais il y avait d'autres
problèmes...

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

Et pourtant, la complexité du truc fait qu'on compare généralement des
machins sous 4D ou FMP faits par des amateurs avec des sqloneries (j'y
intègre Oracle) faites par des pros, qui coutent souvent entre 10 et 100
fois plus chères...

Franchement, des applis métiers en 4D, j'en ai vu pas mal, le seul
sentiment que j'ai c'est : souvent, c'est lourd, môche, on ajoute des
trucs au fur et à mesure de l'évolution du produit et de la demande des
utilisateurs, ça ne respecte aucune règle d'ergonomie de l'interface et
ça en devient vite une plaie à utiliser. Mais, boum, t'es bloqué dedans
parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

Le mieux serait d'avoir des pros qui acceptent de faire des vraies
bases, avec un modèle de donnée solide et des procédure de maintenance
prévues dès l'origine (c'est souvent le problème de fond des bases
d'amateur), mais avec des bon produits comme 4D ou FMP (et en foutant
définitivement à la poubelle cette saloperie d'Access, qui est le pire
de tous...).

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

PS :

Le lien Google de mon post :

<http://groups.google.com/group/fr.comp.os.mac-os.x/browse_thread/thread
/e122e86edc1b86de/d72dd770b4398f62?lnk=st&q=1hkt78e.1ytlgp2mtg0zqN%25lau
rent.pertois%40alussinan.org&rnum=1&hl=en#d72dd770b4398f62>

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

Vous avez filtré cet utilisateur ! Consultez son message

manet wrote:

Laurent Pertois wrote:

Evidemment, mais ça n'est pas impossible,

ah, zut, il me manque tous les messages intermédiaires ; orange wanamou
a loupé son feeding ? j'imagine que tu dis qu'on peut théoriquement
sortir des trucs potables avec MySQL.

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout, ce qu'il y a derrière,
c'est kif-kif, la base de données n'y change rien, si ce n'est les
possibilités et je pense que SQL l'emporte sur FMP (que j'adore par
ailleurs).

j'ai perdu depuis longtemps l'habitude de regarder ce qui est
théoriquement possible ou impossible. Je regarde ce qui existe, ce qu'on
te propose pour de vrai dans la vraie réalité.
Et bien depuis 23 ans que je pratique les bases de données, en
utilisateur, prescripteur ou developpeur, je n'ai jamais vu une
sqlonnerie correcte. C'est un fait.

Tu n'as jamais vu de frontend à SQL correct, je nuançais. Après, on peut
faire des requêtes SQL depuis Excel et faire un masque dans cette appli.
On doit même pouvoir faire ça avec FMP, je suis sûr.

Le B-a-ba, c'est déjà une interface de saisie un minimum ergonomique. Le
boulot qu'il y a à faire sur une sqlonnerie pour mimer un tant soit peu
ce qui existe sur FMP rend déjà un developpement sur commande
difficilement concevable sur le plan économique. Quand on voit ce qui
t'es usuellement proposé... je me crois encore sur mon Apple II avec CX
200 ! ou GCOS 7 sur un Questar 400...

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

faire en partant de zéro une interface avec des boutons radios, des
cases à cocher, des menus déroulants, des listes conditionnelles, avec
un contenu modifiable, des explications qui apparaissent quand tu passe
dessus, c'est effectivement faisable. Mais c'est un tel boulot que ce
n'est économiquement envisageable que sur un petit nombre d'écrans, et
donc sur une base simple. Et dans ce cas, pourquoi donc utiliser
l'artillerie lourde d'une base SQL, avec ce que ça implique comme
problème pour la maintenance... ET par la suite, quand il faut modifier
un truc, en rajouter un, quelle galère... et quel cout ! Résultat, ça
donne des bases figées.

Pas forcément, ce dont tu parles, on le fait déjà dans des pages web, tu
dois pouvoir ainsi faire des développements dont les éléments
d'interface vont pouvoir s'adapter à ce que tu fais. Regarde des
développements comme GMail, il y a pourtant une interface complète avec
derrière une base de données et c'est du client web.

Mais l'ergonomie de l'interface ne résume pas la base de donnée, sinon
on a un joli cimetière de donnée, mais ça reste un cimetière. Par BD
correcte, j'entends mieux, càd une base évolutive, dans laquelle un
utilisateur puisse faire des requetes multicritères et des exports sous
des formats variés sans que cela ait été préprogrammé à l'origine.

C'est toujours programmé à l'origine, tu ne pourras jamais exporter en
Excel dans FMP7, c'est arrivé avec la 8, au mieux tu feras de l'export
texte tabulé ou autre truc basique.

Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Et j'ai vu des gens faire tourner des quantités de données monstrueuses
dans Oracle alors qu'un FMP serait mort rien qu'à l'idée d'en avoir
autant. Et ces données n'étaient pas perdues pour autant...

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein ; que chaque fois que je faisais une exploitation un peu lourde,
je me rendais compte que leurs sorties étaient fausses ; mais je m'en
apercevais parce que j'étais un maniaque, et que j'avais des moyens de
vérification ; résultat, ils corrigeaint, mais il y avait d'autres
problèmes...

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

Et pourtant, la complexité du truc fait qu'on compare généralement des
machins sous 4D ou FMP faits par des amateurs avec des sqloneries (j'y
intègre Oracle) faites par des pros, qui coutent souvent entre 10 et 100
fois plus chères...

Franchement, des applis métiers en 4D, j'en ai vu pas mal, le seul
sentiment que j'ai c'est : souvent, c'est lourd, môche, on ajoute des
trucs au fur et à mesure de l'évolution du produit et de la demande des
utilisateurs, ça ne respecte aucune règle d'ergonomie de l'interface et
ça en devient vite une plaie à utiliser. Mais, boum, t'es bloqué dedans
parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

Le mieux serait d'avoir des pros qui acceptent de faire des vraies
bases, avec un modèle de donnée solide et des procédure de maintenance
prévues dès l'origine (c'est souvent le problème de fond des bases
d'amateur), mais avec des bon produits comme 4D ou FMP (et en foutant
définitivement à la poubelle cette saloperie d'Access, qui est le pire
de tous...).

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

PS :

Le lien Google de mon post :

<http://groups.google.com/group/fr.comp.os.mac-os.x/browse_thread/thread
/e122e86edc1b86de/d72dd770b4398f62?lnk=st&q=1hkt78e.1ytlgp2mtg0zqN%25lau
rent.pertois%40alussinan.org&rnum=1&hl=en#d72dd770b4398f62>

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

nospam

30/08/2006 à 07:38

ASM wrote:

Combien (nbre, prix)?

Nombre 1, prix 1500 Euros négociable mais pas trop :-)

Le clavier n'aura plus ses touches inversées ?

C'est à dire ?
Le seul clavier que j'ai est un clavier QWERTY. Toutefois sur un G5 ça
se change facilement. :-)

La bête est un G5 2 X 2 Ghz avec 1.5 Go de ram, deux disques dur150 Go
et 200 Go. La carte graphique est une GeForce FX 5200. Il est en plus
équipé d'une carte SCSI ATTO UL4S.

Si possible sur Paris, sinon, ça fait des frais en plus, transport et
tripledeal :-)

--
Jacques

filh

30/08/2006 à 07:53

manet wrote:

Laurent Pertois wrote:
Et ce
genre de truc, j'ai vu des dev chevronnés bosser plusieurs années sur
Oracle avant de réussir à faire des trucs qui commencaient seulement à
faire en partie ce que je leur demandais. Et que j'avais pondu dans mon
coin pour mon usage perso en 3 jours sur FMP.

Quand j'entend ça j'ai toujours comme un frisson désagréable.

Comme si il n'existait aucune différence entre fabriquer une caisse à
savon dans son garage et sortir une voiture en prod aux normes de
sécurité.

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

pmanet

30/08/2006 à 23:02

Laurent Pertois wrote:

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout,

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.
Par ailleurs, ce genre de base est justement bien pour SQL : un modèle
de donnée quend meme, a priori, très fruste, des écrans statiques, des
exploitations simples, peu nombreuses et standardisées...

Il y a juste un petit raffinement d'interface, mais qui justement ne
fonctionne correctement que depuis quelques semaines, d'après ce que
j'ai vu : la mise à jour automatique et rapide du prix lors de la config
du produit sans avoir à cliquer sur un bouton en bas. C'est TRES récent
; avant, ils ne savaient pas faire, alors que c'est enfantin avec FMP.
Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

mais il est évident que je ne propose pas de gérer les dizaines de
millions de comptes postaux sur 4D...

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

ben oui ;théoriquement ; super pour faire une jolie maquette qui va
séduire le PDG ; mais c'est vachement simple à maintenir, ça... tous
les ans, il y a un des outils que tu utilisais pour faire ton interface
géniale qui disparait du marché, ou dont la dernière version fournit du
code qui n'est plus compatible avec la dernière version des autres,
etc... galère assurée. C'est LA mauvaise solution.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

ça, c'est valable dans tous les cas. Balle au centre.

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein

le mieux, c'est d'illustrer, mais j'ai encore oublié d'apporter les
requetes de base utilisées dans quelques unes des applis dont je suis
affligé. Quand on voit les 4 lignes de salmigondis que ça représente, on
comprend vite qu'il est impossible de manier des dizaines de trucs comme
ça sans se planter. Ou alors, ça nécessite des mois * homme de
vérification, et c'est trop cher pour etre fait.

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

et alors, où est le problème ? ta base SQL, elle n'est pas verrouillée,
n'importe qui peut y accéder et la bricoler ? bonjour la sécurité.
Et dans le cas contraire, tu es donc pieds et points lié avec ton
developpeur, qui a bien sur sécurisé les accès et crypté les données.
Et je ne suis pas certain qu'il soit plus simple de reprendre un
developpement SQL un peu évolué qu'une base 4D ou FMP de meme
complexité.

On peut faire du developpement libre ou propriétaire avec 4D, FMP ou SQL
de la meme façon ; ce n'est pas l'outil qui compte, mais la relation
entre les dev et les utilisateurs. Tu l'as dit toi-meme : quand tu
developpe, tu utilise des éditeurs que tu paie ; 4D ou FMP sont du meme
tonneau.

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

le problème est justement que plein de gens utilisent Oracle ou MySQL
dans des domaines où la comparaison a un sens, au lieu de les reserver,
ce qui leur leur place, aux applis avec des dizaines de GO de données,
des centaines de connexions simultanées, et plusieurs ingénieurs système
à plein temps.

--
Philippe Manet

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

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout,

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.
Par ailleurs, ce genre de base est justement bien pour SQL : un modèle
de donnée quend meme, a priori, très fruste, des écrans statiques, des
exploitations simples, peu nombreuses et standardisées...

Il y a juste un petit raffinement d'interface, mais qui justement ne
fonctionne correctement que depuis quelques semaines, d'après ce que
j'ai vu : la mise à jour automatique et rapide du prix lors de la config
du produit sans avoir à cliquer sur un bouton en bas. C'est TRES récent
; avant, ils ne savaient pas faire, alors que c'est enfantin avec FMP.
Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

mais il est évident que je ne propose pas de gérer les dizaines de
millions de comptes postaux sur 4D...

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

ben oui ;théoriquement ; super pour faire une jolie maquette qui va
séduire le PDG ; mais c'est vachement simple à maintenir, ça... tous
les ans, il y a un des outils que tu utilisais pour faire ton interface
géniale qui disparait du marché, ou dont la dernière version fournit du
code qui n'est plus compatible avec la dernière version des autres,
etc... galère assurée. C'est LA mauvaise solution.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

ça, c'est valable dans tous les cas. Balle au centre.

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein

le mieux, c'est d'illustrer, mais j'ai encore oublié d'apporter les
requetes de base utilisées dans quelques unes des applis dont je suis
affligé. Quand on voit les 4 lignes de salmigondis que ça représente, on
comprend vite qu'il est impossible de manier des dizaines de trucs comme
ça sans se planter. Ou alors, ça nécessite des mois * homme de
vérification, et c'est trop cher pour etre fait.

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

et alors, où est le problème ? ta base SQL, elle n'est pas verrouillée,
n'importe qui peut y accéder et la bricoler ? bonjour la sécurité.
Et dans le cas contraire, tu es donc pieds et points lié avec ton
developpeur, qui a bien sur sécurisé les accès et crypté les données.
Et je ne suis pas certain qu'il soit plus simple de reprendre un
developpement SQL un peu évolué qu'une base 4D ou FMP de meme
complexité.

On peut faire du developpement libre ou propriétaire avec 4D, FMP ou SQL
de la meme façon ; ce n'est pas l'outil qui compte, mais la relation
entre les dev et les utilisateurs. Tu l'as dit toi-meme : quand tu
developpe, tu utilise des éditeurs que tu paie ; 4D ou FMP sont du meme
tonneau.

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

le problème est justement que plein de gens utilisent Oracle ou MySQL
dans des domaines où la comparaison a un sens, au lieu de les reserver,
ce qui leur leur place, aux applis avec des dizaines de GO de données,
des centaines de connexions simultanées, et plusieurs ingénieurs système
à plein temps.

--
Philippe Manet

Vous avez filtré cet utilisateur ! Consultez son message

Laurent Pertois wrote:

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout,

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.
Par ailleurs, ce genre de base est justement bien pour SQL : un modèle
de donnée quend meme, a priori, très fruste, des écrans statiques, des
exploitations simples, peu nombreuses et standardisées...

Il y a juste un petit raffinement d'interface, mais qui justement ne
fonctionne correctement que depuis quelques semaines, d'après ce que
j'ai vu : la mise à jour automatique et rapide du prix lors de la config
du produit sans avoir à cliquer sur un bouton en bas. C'est TRES récent
; avant, ils ne savaient pas faire, alors que c'est enfantin avec FMP.
Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

mais il est évident que je ne propose pas de gérer les dizaines de
millions de comptes postaux sur 4D...

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

ben oui ;théoriquement ; super pour faire une jolie maquette qui va
séduire le PDG ; mais c'est vachement simple à maintenir, ça... tous
les ans, il y a un des outils que tu utilisais pour faire ton interface
géniale qui disparait du marché, ou dont la dernière version fournit du
code qui n'est plus compatible avec la dernière version des autres,
etc... galère assurée. C'est LA mauvaise solution.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

ça, c'est valable dans tous les cas. Balle au centre.

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein

le mieux, c'est d'illustrer, mais j'ai encore oublié d'apporter les
requetes de base utilisées dans quelques unes des applis dont je suis
affligé. Quand on voit les 4 lignes de salmigondis que ça représente, on
comprend vite qu'il est impossible de manier des dizaines de trucs comme
ça sans se planter. Ou alors, ça nécessite des mois * homme de
vérification, et c'est trop cher pour etre fait.

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

et alors, où est le problème ? ta base SQL, elle n'est pas verrouillée,
n'importe qui peut y accéder et la bricoler ? bonjour la sécurité.
Et dans le cas contraire, tu es donc pieds et points lié avec ton
developpeur, qui a bien sur sécurisé les accès et crypté les données.
Et je ne suis pas certain qu'il soit plus simple de reprendre un
developpement SQL un peu évolué qu'une base 4D ou FMP de meme
complexité.

On peut faire du developpement libre ou propriétaire avec 4D, FMP ou SQL
de la meme façon ; ce n'est pas l'outil qui compte, mais la relation
entre les dev et les utilisateurs. Tu l'as dit toi-meme : quand tu
developpe, tu utilise des éditeurs que tu paie ; 4D ou FMP sont du meme
tonneau.

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

le problème est justement que plein de gens utilisent Oracle ou MySQL
dans des domaines où la comparaison a un sens, au lieu de les reserver,
ce qui leur leur place, aux applis avec des dizaines de GO de données,
des centaines de connexions simultanées, et plusieurs ingénieurs système
à plein temps.

--
Philippe Manet

pmanet

30/08/2006 à 23:02

FiLH wrote:

Comme si il n'existait aucune différence entre fabriquer une caisse à
savon dans son garage et sortir une voiture en prod aux normes de
sécurité.

j'ai dit ailleurs dans le post que je connaissais la différence entre
une appli commerciale et un outil à usage personnel.

Mais ce que j'explique là, c'est que, sous SQL, organiser des mécanismes
permettant à l'usager de faire ce qui est prévu en standard dans 4D ou
FMP (faire une extraction multicritère et un export d'un nombre de
champs non prevu à l'avance sous divers formats choisis par
l'utilisateur) représente une vraie difficulté technique meme pour des
pros qui ne font que ça depuis 15 ans, et qu'il leur faut de longs mois
d'errance et de plantages lamentables pour y arriver partiellement.
Alors que c'est en standard dans les SGDB aggrégés.

Pour des outils pro, ça fait négligé, et je ne comprends pas que les
informaticiens pros acceptent encore de perdre autant de temps à
réinventer la roue. Et là encore, il s'agissait de truc sous Oracle qui
manipulaient quelques dizaines de milliers de ligne, 20 MO de données et
rarement plus de 15 utilisateurs actifs en meme temps. Une indication
parfaite pour des produits plus efficaces.

--
Philippe Manet

laurent.pertois

30/08/2006 à 23:41

manet wrote:

Laurent Pertois wrote:

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout,

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.
Par ailleurs, ce genre de base est justement bien pour SQL : un modèle
de donnée quend meme, a priori, très fruste, des écrans statiques, des
exploitations simples, peu nombreuses et standardisées...

Ben, il n'est pas forcément question de dédier un ingé à une petite base
SQL avec une interface adaptée non plus. Je ne vois pas la différence
entre ce que tu proposes en FMP/4D et un autre produit, il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

Bref, l'outil derrière reste un accessoire pour moi.

Il y a juste un petit raffinement d'interface, mais qui justement ne
fonctionne correctement que depuis quelques semaines, d'après ce que
j'ai vu : la mise à jour automatique et rapide du prix lors de la config
du produit sans avoir à cliquer sur un bouton en bas. C'est TRES récent
; avant, ils ne savaient pas faire, alors que c'est enfantin avec FMP.
Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Et ça le fait aussi dans les versions web de FMP ? (question sérieuse,
je n'ai pas vérifié)

mais il est évident que je ne propose pas de gérer les dizaines de
millions de comptes postaux sur 4D...

Ouf, mais je te rappelle que c'est toi qui a parlé d'Oracle, vu le prix
du bigniou je ne vois pas comment en parler dans une discussion sur une
PME.

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

ben oui ;théoriquement ; super pour faire une jolie maquette qui va
séduire le PDG ; mais c'est vachement simple à maintenir, ça... tous
les ans, il y a un des outils que tu utilisais pour faire ton interface
géniale qui disparait du marché, ou dont la dernière version fournit du
code qui n'est plus compatible avec la dernière version des autres,
etc... galère assurée. C'est LA mauvaise solution.

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS, alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

ça, c'est valable dans tous les cas. Balle au centre.

Yep, mais comme tu mettais en avant cet avantage :)

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein

le mieux, c'est d'illustrer, mais j'ai encore oublié d'apporter les
requetes de base utilisées dans quelques unes des applis dont je suis
affligé. Quand on voit les 4 lignes de salmigondis que ça représente, on
comprend vite qu'il est impossible de manier des dizaines de trucs comme
ça sans se planter. Ou alors, ça nécessite des mois * homme de
vérification, et c'est trop cher pour etre fait.

Euh, tu as déjà vu la gueule des scripts qu'on peut pondre dans FMP ou
des urls de Lasso, je suppose ? ça ne se débugge pas ? question de
maîtrise, une fois de plus...

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

et alors, où est le problème ? ta base SQL, elle n'est pas verrouillée,
n'importe qui peut y accéder et la bricoler ? bonjour la sécurité.

De quoi tu me parles là ?

Et dans le cas contraire, tu es donc pieds et points lié avec ton
developpeur, qui a bien sur sécurisé les accès et crypté les données.

Tss, tss, une base FMP ça se relit comme ça dans tous les cas ?

Et je ne suis pas certain qu'il soit plus simple de reprendre un
developpement SQL un peu évolué qu'une base 4D ou FMP de meme
complexité.

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

On peut faire du developpement libre ou propriétaire avec 4D, FMP ou SQL
de la meme façon ; ce n'est pas l'outil qui compte, mais la relation
entre les dev et les utilisateurs. Tu l'as dit toi-meme : quand tu
developpe, tu utilise des éditeurs que tu paie ; 4D ou FMP sont du meme
tonneau.

Tu vois, on finit par être d'accord, l'important n'est pas tant l'outil
que la façon dont le produit final, ce qui compte le plus, est conçu.

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

le problème est justement que plein de gens utilisent Oracle ou MySQL
dans des domaines où la comparaison a un sens, au lieu de les reserver,
ce qui leur leur place, aux applis avec des dizaines de GO de données,
des centaines de connexions simultanées, et plusieurs ingénieurs système
à plein temps.

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

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

manet <pmanet@invivo.edu> wrote:

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

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout,

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.
Par ailleurs, ce genre de base est justement bien pour SQL : un modèle
de donnée quend meme, a priori, très fruste, des écrans statiques, des
exploitations simples, peu nombreuses et standardisées...

Ben, il n'est pas forcément question de dédier un ingé à une petite base
SQL avec une interface adaptée non plus. Je ne vois pas la différence
entre ce que tu proposes en FMP/4D et un autre produit, il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

Bref, l'outil derrière reste un accessoire pour moi.

Il y a juste un petit raffinement d'interface, mais qui justement ne
fonctionne correctement que depuis quelques semaines, d'après ce que
j'ai vu : la mise à jour automatique et rapide du prix lors de la config
du produit sans avoir à cliquer sur un bouton en bas. C'est TRES récent
; avant, ils ne savaient pas faire, alors que c'est enfantin avec FMP.
Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Et ça le fait aussi dans les versions web de FMP ? (question sérieuse,
je n'ai pas vérifié)

mais il est évident que je ne propose pas de gérer les dizaines de
millions de comptes postaux sur 4D...

Ouf, mais je te rappelle que c'est toi qui a parlé d'Oracle, vu le prix
du bigniou je ne vois pas comment en parler dans une discussion sur une
PME.

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

ben oui ;théoriquement ; super pour faire une jolie maquette qui va
séduire le PDG ; mais c'est vachement simple à maintenir, ça... tous
les ans, il y a un des outils que tu utilisais pour faire ton interface
géniale qui disparait du marché, ou dont la dernière version fournit du
code qui n'est plus compatible avec la dernière version des autres,
etc... galère assurée. C'est LA mauvaise solution.

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS, alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

ça, c'est valable dans tous les cas. Balle au centre.

Yep, mais comme tu mettais en avant cet avantage :)

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein

le mieux, c'est d'illustrer, mais j'ai encore oublié d'apporter les
requetes de base utilisées dans quelques unes des applis dont je suis
affligé. Quand on voit les 4 lignes de salmigondis que ça représente, on
comprend vite qu'il est impossible de manier des dizaines de trucs comme
ça sans se planter. Ou alors, ça nécessite des mois * homme de
vérification, et c'est trop cher pour etre fait.

Euh, tu as déjà vu la gueule des scripts qu'on peut pondre dans FMP ou
des urls de Lasso, je suppose ? ça ne se débugge pas ? question de
maîtrise, une fois de plus...

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

et alors, où est le problème ? ta base SQL, elle n'est pas verrouillée,
n'importe qui peut y accéder et la bricoler ? bonjour la sécurité.

De quoi tu me parles là ?

Et dans le cas contraire, tu es donc pieds et points lié avec ton
developpeur, qui a bien sur sécurisé les accès et crypté les données.

Tss, tss, une base FMP ça se relit comme ça dans tous les cas ?

Et je ne suis pas certain qu'il soit plus simple de reprendre un
developpement SQL un peu évolué qu'une base 4D ou FMP de meme
complexité.

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

On peut faire du developpement libre ou propriétaire avec 4D, FMP ou SQL
de la meme façon ; ce n'est pas l'outil qui compte, mais la relation
entre les dev et les utilisateurs. Tu l'as dit toi-meme : quand tu
developpe, tu utilise des éditeurs que tu paie ; 4D ou FMP sont du meme
tonneau.

Tu vois, on finit par être d'accord, l'important n'est pas tant l'outil
que la façon dont le produit final, ce qui compte le plus, est conçu.

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

le problème est justement que plein de gens utilisent Oracle ou MySQL
dans des domaines où la comparaison a un sens, au lieu de les reserver,
ce qui leur leur place, aux applis avec des dizaines de GO de données,
des centaines de connexions simultanées, et plusieurs ingénieurs système
à plein temps.

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

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

Vous avez filtré cet utilisateur ! Consultez son message

manet wrote:

Laurent Pertois wrote:

Je disais, en substance, que SQL n'y est pour rien, c'est le langage et
le développement du frontend qui change tout,

Euh, là, franchement, ça fait longtemps, effectivement, que tu n'as pas
regardé. Tu penses que l'AppleStore tourne sur une base FMP ?

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.
Par ailleurs, ce genre de base est justement bien pour SQL : un modèle
de donnée quend meme, a priori, très fruste, des écrans statiques, des
exploitations simples, peu nombreuses et standardisées...

Ben, il n'est pas forcément question de dédier un ingé à une petite base
SQL avec une interface adaptée non plus. Je ne vois pas la différence
entre ce que tu proposes en FMP/4D et un autre produit, il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

Bref, l'outil derrière reste un accessoire pour moi.

Il y a juste un petit raffinement d'interface, mais qui justement ne
fonctionne correctement que depuis quelques semaines, d'après ce que
j'ai vu : la mise à jour automatique et rapide du prix lors de la config
du produit sans avoir à cliquer sur un bouton en bas. C'est TRES récent
; avant, ils ne savaient pas faire, alors que c'est enfantin avec FMP.
Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Et ça le fait aussi dans les versions web de FMP ? (question sérieuse,
je n'ai pas vérifié)

mais il est évident que je ne propose pas de gérer les dizaines de
millions de comptes postaux sur 4D...

Ouf, mais je te rappelle que c'est toi qui a parlé d'Oracle, vu le prix
du bigniou je ne vois pas comment en parler dans une discussion sur une
PME.

Et il y a bien d'autres trucs possibles en client web, en mélangeant
différents langages pour développer le frontend.

ben oui ;théoriquement ; super pour faire une jolie maquette qui va
séduire le PDG ; mais c'est vachement simple à maintenir, ça... tous
les ans, il y a un des outils que tu utilisais pour faire ton interface
géniale qui disparait du marché, ou dont la dernière version fournit du
code qui n'est plus compatible avec la dernière version des autres,
etc... galère assurée. C'est LA mauvaise solution.

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS, alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

FMP va proposer éventuellement des facilités de développement du masque,
mais, là encore, si le développeur n'a aucune notion de l'ergonomie,
quoiqu'il utilise, ça sera mauvais !

ça, c'est valable dans tous les cas. Balle au centre.

Yep, mais comme tu mettais en avant cet avantage :)

Le problème, c'est aussi, et surtout, que c'est tellement complexe que
les erreurs sont difficile à debugger, et qu'ils en laissaient trainer
plein

le mieux, c'est d'illustrer, mais j'ai encore oublié d'apporter les
requetes de base utilisées dans quelques unes des applis dont je suis
affligé. Quand on voit les 4 lignes de salmigondis que ça représente, on
comprend vite qu'il est impossible de manier des dizaines de trucs comme
ça sans se planter. Ou alors, ça nécessite des mois * homme de
vérification, et c'est trop cher pour etre fait.

Euh, tu as déjà vu la gueule des scripts qu'on peut pondre dans FMP ou
des urls de Lasso, je suppose ? ça ne se débugge pas ? question de
maîtrise, une fois de plus...

Regarde certaines applis faites en 4D ou en FMP, c'est laid, lourdingue,
il te faut du temps pour comprendre ce qu'il faut faire et c'est buggé
aussi, tout est question de développement, quel que soit
l'environnement.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

parce qu'à part le client 4D développé pour ça, personne ne peut
l'attaquer.

et alors, où est le problème ? ta base SQL, elle n'est pas verrouillée,
n'importe qui peut y accéder et la bricoler ? bonjour la sécurité.

De quoi tu me parles là ?

Et dans le cas contraire, tu es donc pieds et points lié avec ton
developpeur, qui a bien sur sécurisé les accès et crypté les données.

Tss, tss, une base FMP ça se relit comme ça dans tous les cas ?

Et je ne suis pas certain qu'il soit plus simple de reprendre un
developpement SQL un peu évolué qu'une base 4D ou FMP de meme
complexité.

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

On peut faire du developpement libre ou propriétaire avec 4D, FMP ou SQL
de la meme façon ; ce n'est pas l'outil qui compte, mais la relation
entre les dev et les utilisateurs. Tu l'as dit toi-meme : quand tu
developpe, tu utilise des éditeurs que tu paie ; 4D ou FMP sont du meme
tonneau.

Tu vois, on finit par être d'accord, l'important n'est pas tant l'outil
que la façon dont le produit final, ce qui compte le plus, est conçu.

Le problème c'est que comparer Oracle et FMP/4D, ça ne va vraiment pas
être facile...

le problème est justement que plein de gens utilisent Oracle ou MySQL
dans des domaines où la comparaison a un sens, au lieu de les reserver,
ce qui leur leur place, aux applis avec des dizaines de GO de données,
des centaines de connexions simultanées, et plusieurs ingénieurs système
à plein temps.

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

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

ASM

31/08/2006 à 02:27

manet wrote:

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.

il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

En effet, je me concerte avec moi même pour étudier mes besoins.

Bref, l'outil derrière reste un accessoire pour moi.

Non, l'outil est directement lié à la notion d'échelle (du moins c'est
ce que je retire du propos de P. Manet)

Ainsi, dès que je suis d'accord je m'ordonne de créer mon "appli".
Mon département ingénerie choisit alors l'outil adapté, et je me tourne
vers mon ordi pour ouvrir AppleWorks.

Je suis très satisfait de mon département d'ingénieurs qui ne se lance
pas à corps perdu dans MySQL, JavaScript, CSS, HTML, PhotoShop, alors
qu'AW a en standard tout l'outillage nécessaire et suffisant pour
satisfaire ma demande.

Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Je ne pense pas qu'il incrimine la bbd vu que c'est plus une question
d'interface (ses petits moteurs intégrés inexistants dans un SQL) comme
il le précise d'ailleurs : "un petit raffinement d'interface".

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS,

Sauf qu'il faut beaucoup + de temps comme ça tout à la mimime qu'avec un
outil disposant de tout le nécessaire (comme AW)

alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

Oui! c'est pas faux,
je vais être dans le KK quand AW ne tournera plus.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

[... une suite d'égarements ]

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

Je me propose pour le développement en AW.

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

Vous ne pourrez jamais être d'accord.
L'un mettant en avant la virtuosité de développeurs avec une bdd puissante.
L'autre mettant en avant la productivité d'un soft dédié avec une bdd
moyenne mais suffisante.
L'un mettant en avant la pérénité de son usine (ce dont je doute, ça va
tellement vite).
L'autre mettant en avant le choix de l'outil en fonction de l'échelle.

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

--
Stephane Moriaux et son [moins] vieux Mac

manet <pmanet@invivo.edu> wrote:

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.

il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

En effet, je me concerte avec moi même pour étudier mes besoins.

Bref, l'outil derrière reste un accessoire pour moi.

Non, l'outil est directement lié à la notion d'échelle (du moins c'est
ce que je retire du propos de P. Manet)

Ainsi, dès que je suis d'accord je m'ordonne de créer mon "appli".
Mon département ingénerie choisit alors l'outil adapté, et je me tourne
vers mon ordi pour ouvrir AppleWorks.

Je suis très satisfait de mon département d'ingénieurs qui ne se lance
pas à corps perdu dans MySQL, JavaScript, CSS, HTML, PhotoShop, alors
qu'AW a en standard tout l'outillage nécessaire et suffisant pour
satisfaire ma demande.

Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Je ne pense pas qu'il incrimine la bbd vu que c'est plus une question
d'interface (ses petits moteurs intégrés inexistants dans un SQL) comme
il le précise d'ailleurs : "un petit raffinement d'interface".

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS,

Sauf qu'il faut beaucoup + de temps comme ça tout à la mimime qu'avec un
outil disposant de tout le nécessaire (comme AW)

alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

Oui! c'est pas faux,
je vais être dans le KK quand AW ne tournera plus.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

[... une suite d'égarements ]

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

Je me propose pour le développement en AW.

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

Vous ne pourrez jamais être d'accord.
L'un mettant en avant la virtuosité de développeurs avec une bdd puissante.
L'autre mettant en avant la productivité d'un soft dédié avec une bdd
moyenne mais suffisante.
L'un mettant en avant la pérénité de son usine (ce dont je doute, ça va
tellement vite).
L'autre mettant en avant le choix de l'outil en fonction de l'échelle.

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

--
Stephane Moriaux et son [moins] vieux Mac

Vous avez filtré cet utilisateur ! Consultez son message

manet wrote:

ça n'a rien à voir ; on parlait d'utiliser SQL pour des applis destinées
à quelques utilisateurs, pas pour des besoins commerciaux à grande
échelle de milliers de connexions à l'heure, sur lesquels on peut
effectivement amortir 2-3 ingenieurs à temps plein.

il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

En effet, je me concerte avec moi même pour étudier mes besoins.

Bref, l'outil derrière reste un accessoire pour moi.

Non, l'outil est directement lié à la notion d'échelle (du moins c'est
ce que je retire du propos de P. Manet)

Ainsi, dès que je suis d'accord je m'ordonne de créer mon "appli".
Mon département ingénerie choisit alors l'outil adapté, et je me tourne
vers mon ordi pour ouvrir AppleWorks.

Je suis très satisfait de mon département d'ingénieurs qui ne se lance
pas à corps perdu dans MySQL, JavaScript, CSS, HTML, PhotoShop, alors
qu'AW a en standard tout l'outillage nécessaire et suffisant pour
satisfaire ma demande.

Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Je ne pense pas qu'il incrimine la bbd vu que c'est plus une question
d'interface (ses petits moteurs intégrés inexistants dans un SQL) comme
il le précise d'ailleurs : "un petit raffinement d'interface".

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS,

Sauf qu'il faut beaucoup + de temps comme ça tout à la mimime qu'avec un
outil disposant de tout le nécessaire (comme AW)

alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

Oui! c'est pas faux,
je vais être dans le KK quand AW ne tournera plus.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

[... une suite d'égarements ]

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

Je me propose pour le développement en AW.

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

Vous ne pourrez jamais être d'accord.
L'un mettant en avant la virtuosité de développeurs avec une bdd puissante.
L'autre mettant en avant la productivité d'un soft dédié avec une bdd
moyenne mais suffisante.
L'un mettant en avant la pérénité de son usine (ce dont je doute, ça va
tellement vite).
L'autre mettant en avant le choix de l'outil en fonction de l'échelle.

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

--
Stephane Moriaux et son [moins] vieux Mac

laurent.pertois

31/08/2006 à 03:43

ASM wrote:

il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

En effet, je me concerte avec moi même pour étudier mes besoins.

Avec une équipe réduite, on va souvent vite, surtout quand toutes les
compétences sont bien réparties et réunies.

Bref, l'outil derrière reste un accessoire pour moi.

Non, l'outil est directement lié à la notion d'échelle (du moins c'est
ce que je retire du propos de P. Manet)

Oui, mais une société qui se retrouve acculée une fois à un problème
d'incompatibilité va aussi devoir envisager le long terme comme le
mentionnait Nina. Chat échaudé peut craindre l'eau froide (parfois à
tort, je le reconnais).

Ainsi, dès que je suis d'accord je m'ordonne de créer mon "appli".
Mon département ingénerie choisit alors l'outil adapté, et je me tourne
vers mon ordi pour ouvrir AppleWorks.

Choix qui, dans quelques années, ne sera pas sans poser de problèmes,
ton département ingénierie n'envisage pas suffisamment le long terme à
mon goût.

Je suis très satisfait de mon département d'ingénieurs qui ne se lance
pas à corps perdu dans MySQL, JavaScript, CSS, HTML, PhotoShop, alors
qu'AW a en standard tout l'outillage nécessaire et suffisant pour
satisfaire ma demande.

Oui, mais, dans, disons 3 ans, tu te retourneras vers ton département
ingéniérie quand tu commenceras à avoir des soucis car le développement,
validé pourtant en son temps par la direction, commencera à poser des
soucis et tu leur demanderas alors une nouvelle solution tout en les
blâmant de ne pas avoir anticipé.

Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Je ne pense pas qu'il incrimine la bbd vu que c'est plus une question
d'interface (ses petits moteurs intégrés inexistants dans un SQL) comme
il le précise d'ailleurs : "un petit raffinement d'interface".

<mauvais foi>

Euh, il parlait bien de SQLonneries, il me semble, pas de PHPonneries ou
autres...

</>

Il accuse quand même SQL d'être un système dépassé, indébuggable,
vieillot et impossible à utiliser, il me semble. L'interface doit je
pense bien être distinguée de ce qu'il y a derrière.

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS,

Sauf qu'il faut beaucoup + de temps comme ça tout à la mimime qu'avec un
outil disposant de tout le nécessaire (comme AW)

Pas forcément, déjà tu n'es pas obligé de faire appel aux mêmes
personnes pour le faire, ce qui permet aussi de prendre des personnes
compétentes dans leur domaine. Qu'un outil fournisse "tout le
nécessaire" est une bonne chose, mon expérience me pousse cependant à
dire que les outils multiplateformes ne font souvent qu'un pis-aller sur
chacune sans faire un objet vraiment intégré à chaque fois, il n'est
qu'à voir les propos de Momoclic qui précise qu'il faut rester dans les
standard et que parfois les boutons peuvent poser problème. De plus,
même si je fais du monoplateforme, je n'ai jamais vu dans FMP de quoi
imposer au développeur une interface conforme à Mac OS X comme le fait
Interface Builder en mettant des guides de positionnement des boutons et
autres.

alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

Oui! c'est pas faux,
je vais être dans le KK quand AW ne tournera plus.

Je te l'ai dit, tu es satisfait de ton département ingéniérie mais il
n'envisage pas le long terme.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

[... une suite d'égarements ]

??

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

Je me propose pour le développement en AW.

Je suis désolé, votre proposition, bien qu'ayant de sérieuses
références, n'a pu retenir pleinement notre attention car nous pensons
que notre société survivra à cette année...

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

Vous ne pourrez jamais être d'accord.

Je ne fais que donner des arguments, j'aime bien FMP, je l'utilise
moi-même, il a ses avantages, c'est dire. Je ne trouve pas qu'il fasse
des applis merveilleusement belles au regard de l'interface de Mac OS X,
il nécessite aussi un énorme travail de mise en place de l'interface
surtout quand il doit être mis dans les mains d'utilisateurs novices.

L'un mettant en avant la virtuosité de développeurs avec une bdd puissante.
L'autre mettant en avant la productivité d'un soft dédié avec une bdd
moyenne mais suffisante.

Je ne cherche pas à dire que tous les développeurs qui tournent autour
de SQL sont des virtuoses, j'ai vu plein d'horreurs. Je ne cherche pas à
dire que FMP, dans le cas qui nous intéresse est insuffisant et qu'il
faut absolument du SQL, je ne cherche qu'à rappeler que l'outil qui est
derrière n'est pas tout, un développeur, quelle que soit son outil, doit
envisager aussi l'interface, le meilleur outil du monde le laissera
aussi faire des horreurs.

L'un mettant en avant la pérénité de son usine (ce dont je doute, ça va
tellement vite).

Bah, j'essaie de l'envisager. Je n'ai jamais dit que c'était parfait
mais disons que SQL est là depuis pas mal de temps, les dumps sont
connus et réinjectables, même à mon petit niveau dans ce domaine je l'ai
déjà expérimenté. Cela dit, des outils comme FMP sont aussi capables de
le faire. Disons que le côté open source d'un MySQL, sans être le saint
graâl (non, je n'ai pas dit qu'il fallait tout faire en open source,
pitié) assure aussi de pouvoir au moins refaire à minima ce que faisait
l'original, un FMP, si ça plie un jour, ben...

L'autre mettant en avant le choix de l'outil en fonction de l'échelle.

Ah mais je n'ai jamais dit que, dans le cas qui a constitué notre point
de départ, il fallait _absolument_ prendre un truc de malades.

Pour tout dire, j'ai suivi la mise en place d'une grosse appli sur FMP
(grosse car pièce importante du département d'une entreprise de bonne
taille). Eh bien, le développeur, chevronné dans ce domaine, a passé
déjà énormément de temps à définir la structure de sa base, ensuite les
liaisons entre les éléments et, pour finir, beaucoup de temps avec les
utilisateurs pour leur simplifier la vie. Au final, ça ne s'est pas fait
en deux temps trois mouvements. FMP était parfaitement adapté au besoin,
pas de soucis de ce point de vue, j'ai même eu à donner mon avis, je
n'ai pas cherché à influencer vers autre chose, sachant que ce serait
bon et, surtout, qu'il y avait sur place la personne compétente. Mais,
la raison qui les a poussé à faire tout ça, et ce développement qui a
duré pas loin de 6 mois, a été le passage à la version 7 de FileMaker
qui, pour profiter pleinement de ses nouvelles possibilités, ne pouvait
pas passer par un simple import de l'existant (comme quoi, les meilleurs
outils, quand ils évoluent vraiment, nécessitent aussi parfois de casser
l'existant). Cela dit, au final, le gros avantage a été une énorme
optimisation et surtout l'élimination de tous les petits "patchs"
apportés à la version précédente pour en faire un produit plus conforme
à l'utilisation.

Cependant, au vu de l'utilisation à travers un navigateur, on aurait
tout à fait pu avoir la même chose dans une autre BDD comme un SQL, la
preuve, on a même eu droit à une maquette dont l'interface ressemblait à
la version FMP lorsqu'il a fallu faire le choix, c'est dire...

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

AppleWorks ne saurait pas faire ? ;-)

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

ASM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

En effet, je me concerte avec moi même pour étudier mes besoins.

Avec une équipe réduite, on va souvent vite, surtout quand toutes les
compétences sont bien réparties et réunies.

Bref, l'outil derrière reste un accessoire pour moi.

Non, l'outil est directement lié à la notion d'échelle (du moins c'est
ce que je retire du propos de P. Manet)

Oui, mais une société qui se retrouve acculée une fois à un problème
d'incompatibilité va aussi devoir envisager le long terme comme le
mentionnait Nina. Chat échaudé peut craindre l'eau froide (parfois à
tort, je le reconnais).

Ainsi, dès que je suis d'accord je m'ordonne de créer mon "appli".
Mon département ingénerie choisit alors l'outil adapté, et je me tourne
vers mon ordi pour ouvrir AppleWorks.

Choix qui, dans quelques années, ne sera pas sans poser de problèmes,
ton département ingénierie n'envisage pas suffisamment le long terme à
mon goût.

Je suis très satisfait de mon département d'ingénieurs qui ne se lance
pas à corps perdu dans MySQL, JavaScript, CSS, HTML, PhotoShop, alors
qu'AW a en standard tout l'outillage nécessaire et suffisant pour
satisfaire ma demande.

Oui, mais, dans, disons 3 ans, tu te retourneras vers ton département
ingéniérie quand tu commenceras à avoir des soucis car le développement,
validé pourtant en son temps par la direction, commencera à poser des
soucis et tu leur demanderas alors une nouvelle solution tout en les
blâmant de ne pas avoir anticipé.

Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Je ne pense pas qu'il incrimine la bbd vu que c'est plus une question
d'interface (ses petits moteurs intégrés inexistants dans un SQL) comme
il le précise d'ailleurs : "un petit raffinement d'interface".

<mauvais foi>

Euh, il parlait bien de SQLonneries, il me semble, pas de PHPonneries ou
autres...

</>

Il accuse quand même SQL d'être un système dépassé, indébuggable,
vieillot et impossible à utiliser, il me semble. L'interface doit je
pense bien être distinguée de ce qu'il y a derrière.

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS,

Sauf qu'il faut beaucoup + de temps comme ça tout à la mimime qu'avec un
outil disposant de tout le nécessaire (comme AW)

Pas forcément, déjà tu n'es pas obligé de faire appel aux mêmes
personnes pour le faire, ce qui permet aussi de prendre des personnes
compétentes dans leur domaine. Qu'un outil fournisse "tout le
nécessaire" est une bonne chose, mon expérience me pousse cependant à
dire que les outils multiplateformes ne font souvent qu'un pis-aller sur
chacune sans faire un objet vraiment intégré à chaque fois, il n'est
qu'à voir les propos de Momoclic qui précise qu'il faut rester dans les
standard et que parfois les boutons peuvent poser problème. De plus,
même si je fais du monoplateforme, je n'ai jamais vu dans FMP de quoi
imposer au développeur une interface conforme à Mac OS X comme le fait
Interface Builder en mettant des guides de positionnement des boutons et
autres.

alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

Oui! c'est pas faux,
je vais être dans le KK quand AW ne tournera plus.

Je te l'ai dit, tu es satisfait de ton département ingéniérie mais il
n'envisage pas le long terme.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

[... une suite d'égarements ]

??

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

Je me propose pour le développement en AW.

Je suis désolé, votre proposition, bien qu'ayant de sérieuses
références, n'a pu retenir pleinement notre attention car nous pensons
que notre société survivra à cette année...

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

Vous ne pourrez jamais être d'accord.

Je ne fais que donner des arguments, j'aime bien FMP, je l'utilise
moi-même, il a ses avantages, c'est dire. Je ne trouve pas qu'il fasse
des applis merveilleusement belles au regard de l'interface de Mac OS X,
il nécessite aussi un énorme travail de mise en place de l'interface
surtout quand il doit être mis dans les mains d'utilisateurs novices.

L'un mettant en avant la virtuosité de développeurs avec une bdd puissante.
L'autre mettant en avant la productivité d'un soft dédié avec une bdd
moyenne mais suffisante.

Je ne cherche pas à dire que tous les développeurs qui tournent autour
de SQL sont des virtuoses, j'ai vu plein d'horreurs. Je ne cherche pas à
dire que FMP, dans le cas qui nous intéresse est insuffisant et qu'il
faut absolument du SQL, je ne cherche qu'à rappeler que l'outil qui est
derrière n'est pas tout, un développeur, quelle que soit son outil, doit
envisager aussi l'interface, le meilleur outil du monde le laissera
aussi faire des horreurs.

L'un mettant en avant la pérénité de son usine (ce dont je doute, ça va
tellement vite).

Bah, j'essaie de l'envisager. Je n'ai jamais dit que c'était parfait
mais disons que SQL est là depuis pas mal de temps, les dumps sont
connus et réinjectables, même à mon petit niveau dans ce domaine je l'ai
déjà expérimenté. Cela dit, des outils comme FMP sont aussi capables de
le faire. Disons que le côté open source d'un MySQL, sans être le saint
graâl (non, je n'ai pas dit qu'il fallait tout faire en open source,
pitié) assure aussi de pouvoir au moins refaire à minima ce que faisait
l'original, un FMP, si ça plie un jour, ben...

L'autre mettant en avant le choix de l'outil en fonction de l'échelle.

Ah mais je n'ai jamais dit que, dans le cas qui a constitué notre point
de départ, il fallait _absolument_ prendre un truc de malades.

Pour tout dire, j'ai suivi la mise en place d'une grosse appli sur FMP
(grosse car pièce importante du département d'une entreprise de bonne
taille). Eh bien, le développeur, chevronné dans ce domaine, a passé
déjà énormément de temps à définir la structure de sa base, ensuite les
liaisons entre les éléments et, pour finir, beaucoup de temps avec les
utilisateurs pour leur simplifier la vie. Au final, ça ne s'est pas fait
en deux temps trois mouvements. FMP était parfaitement adapté au besoin,
pas de soucis de ce point de vue, j'ai même eu à donner mon avis, je
n'ai pas cherché à influencer vers autre chose, sachant que ce serait
bon et, surtout, qu'il y avait sur place la personne compétente. Mais,
la raison qui les a poussé à faire tout ça, et ce développement qui a
duré pas loin de 6 mois, a été le passage à la version 7 de FileMaker
qui, pour profiter pleinement de ses nouvelles possibilités, ne pouvait
pas passer par un simple import de l'existant (comme quoi, les meilleurs
outils, quand ils évoluent vraiment, nécessitent aussi parfois de casser
l'existant). Cela dit, au final, le gros avantage a été une énorme
optimisation et surtout l'élimination de tous les petits "patchs"
apportés à la version précédente pour en faire un produit plus conforme
à l'utilisation.

Cependant, au vu de l'utilisation à travers un navigateur, on aurait
tout à fait pu avoir la même chose dans une autre BDD comme un SQL, la
preuve, on a même eu droit à une maquette dont l'interface ressemblait à
la version FMP lorsqu'il a fallu faire le choix, c'est dire...

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

AppleWorks ne saurait pas faire ? ;-)

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

Vous avez filtré cet utilisateur ! Consultez son message

ASM wrote:

il faut du
développement fait par quelqu'un qui connaît l'environnement choisi,
c'est tout. Et après, il faut expliquer à ce développeur ce qu'on veut
vraiment, en discuter avec lui pour définir l'interface voulue et que
lui confronte avec ce qu'il recommande également.

En effet, je me concerte avec moi même pour étudier mes besoins.

Avec une équipe réduite, on va souvent vite, surtout quand toutes les
compétences sont bien réparties et réunies.

Bref, l'outil derrière reste un accessoire pour moi.

Non, l'outil est directement lié à la notion d'échelle (du moins c'est
ce que je retire du propos de P. Manet)

Oui, mais une société qui se retrouve acculée une fois à un problème
d'incompatibilité va aussi devoir envisager le long terme comme le
mentionnait Nina. Chat échaudé peut craindre l'eau froide (parfois à
tort, je le reconnais).

Ainsi, dès que je suis d'accord je m'ordonne de créer mon "appli".
Mon département ingénerie choisit alors l'outil adapté, et je me tourne
vers mon ordi pour ouvrir AppleWorks.

Choix qui, dans quelques années, ne sera pas sans poser de problèmes,
ton département ingénierie n'envisage pas suffisamment le long terme à
mon goût.

Je suis très satisfait de mon département d'ingénieurs qui ne se lance
pas à corps perdu dans MySQL, JavaScript, CSS, HTML, PhotoShop, alors
qu'AW a en standard tout l'outillage nécessaire et suffisant pour
satisfaire ma demande.

Oui, mais, dans, disons 3 ans, tu te retourneras vers ton département
ingéniérie quand tu commenceras à avoir des soucis car le développement,
validé pourtant en son temps par la direction, commencera à poser des
soucis et tu leur demanderas alors une nouvelle solution tout en les
blâmant de ne pas avoir anticipé.

Juste pour dire : il leur a fallu 10 ans pour reussir à faire ce qu'on
fait en 10 minutes avec un bon SGDB.

Et qui te dit que ça vient de la bdd derrière ?

Je ne pense pas qu'il incrimine la bbd vu que c'est plus une question
d'interface (ses petits moteurs intégrés inexistants dans un SQL) comme
il le précise d'ailleurs : "un petit raffinement d'interface".

<mauvais foi>

Euh, il parlait bien de SQLonneries, il me semble, pas de PHPonneries ou
autres...

</>

Il accuse quand même SQL d'être un système dépassé, indébuggable,
vieillot et impossible à utiliser, il me semble. L'interface doit je
pense bien être distinguée de ce qu'il y a derrière.

Euh, tu pars du principe que le code va être fait forcément dans un
outil graphique... Parce que bon, faire des boutons en png et taper du
code JS et HTML, je n'ai pas forcément besoin d'un outil puissant qui va
disparaître, un éditeur de texte, je pense en trouver pendant longtemps
sur les OS,

Sauf qu'il faut beaucoup + de temps comme ça tout à la mimime qu'avec un
outil disposant de tout le nécessaire (comme AW)

Pas forcément, déjà tu n'es pas obligé de faire appel aux mêmes
personnes pour le faire, ce qui permet aussi de prendre des personnes
compétentes dans leur domaine. Qu'un outil fournisse "tout le
nécessaire" est une bonne chose, mon expérience me pousse cependant à
dire que les outils multiplateformes ne font souvent qu'un pis-aller sur
chacune sans faire un objet vraiment intégré à chaque fois, il n'est
qu'à voir les propos de Momoclic qui précise qu'il faut rester dans les
standard et que parfois les boutons peuvent poser problème. De plus,
même si je fais du monoplateforme, je n'ai jamais vu dans FMP de quoi
imposer au développeur une interface conforme à Mac OS X comme le fait
Interface Builder en mettant des guides de positionnement des boutons et
autres.

alors qu'un 4D ou un FMP pour pondre l'interface ou dont
l'appli cliente fournie par le développeur ne tourne plus sur les
dernières versions de l'OS, ça, j'en ai aussi vu pas mal, la preuve,
c'est même à cause de ça qu'on a commencé à en discuter.

Oui! c'est pas faux,
je vais être dans le KK quand AW ne tournera plus.

Je te l'ai dit, tu es satisfait de ton département ingéniérie mais il
n'envisage pas le long terme.

oui, mais ensuite vient le cout du developpement, qui est liè à
l'ergonomie des outils, à résultat égal.

Ben oui, c'est ce que je me tue à te dire.

[... une suite d'égarements ]

??

Je pense qu'au jour d'aujourd'hui je trouve plus facilement des
développeurs maîtrisant bien le SQL que le 4D ou le FMP, malheureusement
pour ces deux dernier produits.

Je me propose pour le développement en AW.

Je suis désolé, votre proposition, bien qu'ayant de sérieuses
références, n'a pu retenir pleinement notre attention car nous pensons
que notre société survivra à cette année...

Voui, je n'ai pas recommandé Oracle, SQL ou autre chose dans tous les
cas, je voulais juste dire que l'interface entre l'utilisateur et la BDD
n'a rien à voir avec cette dernière, c'est du développement.

Vous ne pourrez jamais être d'accord.

Je ne fais que donner des arguments, j'aime bien FMP, je l'utilise
moi-même, il a ses avantages, c'est dire. Je ne trouve pas qu'il fasse
des applis merveilleusement belles au regard de l'interface de Mac OS X,
il nécessite aussi un énorme travail de mise en place de l'interface
surtout quand il doit être mis dans les mains d'utilisateurs novices.

L'un mettant en avant la virtuosité de développeurs avec une bdd puissante.
L'autre mettant en avant la productivité d'un soft dédié avec une bdd
moyenne mais suffisante.

Je ne cherche pas à dire que tous les développeurs qui tournent autour
de SQL sont des virtuoses, j'ai vu plein d'horreurs. Je ne cherche pas à
dire que FMP, dans le cas qui nous intéresse est insuffisant et qu'il
faut absolument du SQL, je ne cherche qu'à rappeler que l'outil qui est
derrière n'est pas tout, un développeur, quelle que soit son outil, doit
envisager aussi l'interface, le meilleur outil du monde le laissera
aussi faire des horreurs.

L'un mettant en avant la pérénité de son usine (ce dont je doute, ça va
tellement vite).

Bah, j'essaie de l'envisager. Je n'ai jamais dit que c'était parfait
mais disons que SQL est là depuis pas mal de temps, les dumps sont
connus et réinjectables, même à mon petit niveau dans ce domaine je l'ai
déjà expérimenté. Cela dit, des outils comme FMP sont aussi capables de
le faire. Disons que le côté open source d'un MySQL, sans être le saint
graâl (non, je n'ai pas dit qu'il fallait tout faire en open source,
pitié) assure aussi de pouvoir au moins refaire à minima ce que faisait
l'original, un FMP, si ça plie un jour, ben...

L'autre mettant en avant le choix de l'outil en fonction de l'échelle.

Ah mais je n'ai jamais dit que, dans le cas qui a constitué notre point
de départ, il fallait _absolument_ prendre un truc de malades.

Pour tout dire, j'ai suivi la mise en place d'une grosse appli sur FMP
(grosse car pièce importante du département d'une entreprise de bonne
taille). Eh bien, le développeur, chevronné dans ce domaine, a passé
déjà énormément de temps à définir la structure de sa base, ensuite les
liaisons entre les éléments et, pour finir, beaucoup de temps avec les
utilisateurs pour leur simplifier la vie. Au final, ça ne s'est pas fait
en deux temps trois mouvements. FMP était parfaitement adapté au besoin,
pas de soucis de ce point de vue, j'ai même eu à donner mon avis, je
n'ai pas cherché à influencer vers autre chose, sachant que ce serait
bon et, surtout, qu'il y avait sur place la personne compétente. Mais,
la raison qui les a poussé à faire tout ça, et ce développement qui a
duré pas loin de 6 mois, a été le passage à la version 7 de FileMaker
qui, pour profiter pleinement de ses nouvelles possibilités, ne pouvait
pas passer par un simple import de l'existant (comme quoi, les meilleurs
outils, quand ils évoluent vraiment, nécessitent aussi parfois de casser
l'existant). Cela dit, au final, le gros avantage a été une énorme
optimisation et surtout l'élimination de tous les petits "patchs"
apportés à la version précédente pour en faire un produit plus conforme
à l'utilisation.

Cependant, au vu de l'utilisation à travers un navigateur, on aurait
tout à fait pu avoir la même chose dans une autre BDD comme un SQL, la
preuve, on a même eu droit à une maquette dont l'interface ressemblait à
la version FMP lorsqu'il a fallu faire le choix, c'est dire...

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

AppleWorks ne saurait pas faire ? ;-)

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

ASM

31/08/2006 à 05:09

ASM wrote:

Oui, mais, dans, disons 3 ans, tu te retourneras vers ton département
ingéniérie quand tu commenceras à avoir des soucis,

Pas seulement pour le maintien,
il va aussi avoir des soucis quand je lui demanderai de me fournir des
sorties à partir d'archives :-(

il le précise d'ailleurs : "un petit raffinement d'interface".

<mauvaise foi>

Ha ! tu l'admets :-)

Euh, il parlait bien de SQLonneries, il me semble, pas de PHPonneries ou
autres...

Faut bien avouer que ces SQLonneries faut s'les farcir.

Il accuse quand même SQL d'être un système dépassé, indébuggable,
vieillot et impossible à utiliser, il me semble.

A t-il tord ?
Il doit bien il y avoir une nouveauté décoiffante qui se pointe à
l'horizon ?

L'interface doit je
pense bien être distinguée de ce qu'il y a derrière.

C'est bien ça qui pêche.
Le manque d'outil d'interfaçage.
Enfin je crois ?
Bien qu'ici :
<http://www.versiontracker.com/php/search.php?action=search&str=sql&plt%5B%5D=macosx>
p't'et' bien qu'il y a de quoi ?

[... une suite d'égarements ]

??

Ben oui, des chicornages HS.

Je me propose pour le développement en AW.

Je suis désolé, votre proposition, bien qu'

Rhâ la la ! Bien déçu.

Vous ne pourrez jamais être d'accord.

Je ne fais que donner des arguments, j'aime bien FMP, je l'utilise
moi-même, il a ses avantages, c'est dire. Je ne trouve pas qu'il fasse
des applis merveilleusement belles au regard de l'interface de Mac OS X,

Bon, y a longtemps que je n'ai pas regardé FM
et il est certain qu'à l'époque il n'était pas vraiment "aqua"

il nécessite aussi un énorme travail de mise en place de l'interface
surtout quand il doit être mis dans les mains d'utilisateurs novices.

Même avec AW y a du boulot et pourtant il peut moins qu'un FM ou 4D.
Comme tu disais l'interface demande un maximum de réflexion.
Néanmoins, et à mon idée, sans commune mesure entre partir de rien (avec
son éditeur-texte) et un outil assez adapté.

Je ne cherche pas à dire que tous les développeurs qui tournent autour
de SQL sont des virtuoses,

Il vaudrait cependant mieux.
Je bricole MySql et je vois bien que c'est pas terrible.
Qu'après avoir transpiré à grosses gouttes un truc qui fonctionne enfin,
je suis bien certain que l'optimisation n'est pas au rendez-vous.

j'ai vu plein d'horreurs.

Oui ... l'ergonomie ... un métier.

disons que SQL est là depuis pas mal de temps, les dumps sont
connus et réinjectables, même à mon petit niveau dans ce domaine je l'ai
déjà expérimenté. Cela dit, des outils comme FMP sont aussi capables de
le faire. Disons que le côté open source d'un MySQL, sans être le saint
graâl (non, je n'ai pas dit qu'il fallait tout faire en open source,
pitié) assure aussi de pouvoir au moins refaire à minima ce que faisait
l'original, un FMP, si ça plie un jour, ben...

Je me te traduit :
c'est pas difficile de faire en MySql ce que faisait une appli FMP.
C'est ce que tu dis ?
P. Manet n'a pas l'air de le penser.

Pour tout dire, j'ai suivi la mise en place d'une grosse appli sur FMP
(grosse car pièce importante du département d'une entreprise de bonne
taille). Eh bien, le développeur, chevronné dans ce domaine, a passé
déjà énormément de temps à définir la structure de sa base, ensuite les
liaisons entre les éléments

Est-ce que ça n'aurait pas été pareil avec MySql ?
Les tables ne se définissent ni ne se créent toutes seules.
Pareil pour les clès de l'une à l'autre me semble-ce.

et, pour finir, beaucoup de temps avec les
utilisateurs pour leur simplifier la vie.

ergonomie ergonomie

Cependant, au vu de l'utilisation à travers un navigateur, on aurait
tout à fait pu avoir la même chose dans une autre BDD comme un SQL, la
preuve, on a même eu droit à une maquette dont l'interface ressemblait à
la version FMP lorsqu'il a fallu faire le choix, c'est dire...

Entre une maquette (un écran à boutons inopérants) et le définitif il y
a une marge, les 6 mois de l'évolution auraient-ils suffit ?

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

AppleWorks ne saurait pas faire ? ;-)

J'attends les plug-in pour iWeb :-)

--
Stephane Moriaux et son [moins] vieux Mac

ASM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> wrote:

Oui, mais, dans, disons 3 ans, tu te retourneras vers ton département
ingéniérie quand tu commenceras à avoir des soucis,

Pas seulement pour le maintien,
il va aussi avoir des soucis quand je lui demanderai de me fournir des
sorties à partir d'archives :-(

il le précise d'ailleurs : "un petit raffinement d'interface".

<mauvaise foi>

Ha ! tu l'admets :-)

Euh, il parlait bien de SQLonneries, il me semble, pas de PHPonneries ou
autres...

Faut bien avouer que ces SQLonneries faut s'les farcir.

Il accuse quand même SQL d'être un système dépassé, indébuggable,
vieillot et impossible à utiliser, il me semble.

A t-il tord ?
Il doit bien il y avoir une nouveauté décoiffante qui se pointe à
l'horizon ?

L'interface doit je
pense bien être distinguée de ce qu'il y a derrière.

C'est bien ça qui pêche.
Le manque d'outil d'interfaçage.
Enfin je crois ?
Bien qu'ici :
<http://www.versiontracker.com/php/search.php?action=search&str=sql&plt%5B%5D=macosx>
p't'et' bien qu'il y a de quoi ?

[... une suite d'égarements ]

??

Ben oui, des chicornages HS.

Je me propose pour le développement en AW.

Je suis désolé, votre proposition, bien qu'

Rhâ la la ! Bien déçu.

Vous ne pourrez jamais être d'accord.

Je ne fais que donner des arguments, j'aime bien FMP, je l'utilise
moi-même, il a ses avantages, c'est dire. Je ne trouve pas qu'il fasse
des applis merveilleusement belles au regard de l'interface de Mac OS X,

Bon, y a longtemps que je n'ai pas regardé FM
et il est certain qu'à l'époque il n'était pas vraiment "aqua"

il nécessite aussi un énorme travail de mise en place de l'interface
surtout quand il doit être mis dans les mains d'utilisateurs novices.

Même avec AW y a du boulot et pourtant il peut moins qu'un FM ou 4D.
Comme tu disais l'interface demande un maximum de réflexion.
Néanmoins, et à mon idée, sans commune mesure entre partir de rien (avec
son éditeur-texte) et un outil assez adapté.

Je ne cherche pas à dire que tous les développeurs qui tournent autour
de SQL sont des virtuoses,

Il vaudrait cependant mieux.
Je bricole MySql et je vois bien que c'est pas terrible.
Qu'après avoir transpiré à grosses gouttes un truc qui fonctionne enfin,
je suis bien certain que l'optimisation n'est pas au rendez-vous.

j'ai vu plein d'horreurs.

Oui ... l'ergonomie ... un métier.

disons que SQL est là depuis pas mal de temps, les dumps sont
connus et réinjectables, même à mon petit niveau dans ce domaine je l'ai
déjà expérimenté. Cela dit, des outils comme FMP sont aussi capables de
le faire. Disons que le côté open source d'un MySQL, sans être le saint
graâl (non, je n'ai pas dit qu'il fallait tout faire en open source,
pitié) assure aussi de pouvoir au moins refaire à minima ce que faisait
l'original, un FMP, si ça plie un jour, ben...

Je me te traduit :
c'est pas difficile de faire en MySql ce que faisait une appli FMP.
C'est ce que tu dis ?
P. Manet n'a pas l'air de le penser.

Pour tout dire, j'ai suivi la mise en place d'une grosse appli sur FMP
(grosse car pièce importante du département d'une entreprise de bonne
taille). Eh bien, le développeur, chevronné dans ce domaine, a passé
déjà énormément de temps à définir la structure de sa base, ensuite les
liaisons entre les éléments

Est-ce que ça n'aurait pas été pareil avec MySql ?
Les tables ne se définissent ni ne se créent toutes seules.
Pareil pour les clès de l'une à l'autre me semble-ce.

et, pour finir, beaucoup de temps avec les
utilisateurs pour leur simplifier la vie.

ergonomie ergonomie

Cependant, au vu de l'utilisation à travers un navigateur, on aurait
tout à fait pu avoir la même chose dans une autre BDD comme un SQL, la
preuve, on a même eu droit à une maquette dont l'interface ressemblait à
la version FMP lorsqu'il a fallu faire le choix, c'est dire...

Entre une maquette (un écran à boutons inopérants) et le définitif il y
a une marge, les 6 mois de l'évolution auraient-ils suffit ?

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

AppleWorks ne saurait pas faire ? ;-)

J'attends les plug-in pour iWeb :-)

--
Stephane Moriaux et son [moins] vieux Mac

Vous avez filtré cet utilisateur ! Consultez son message

ASM wrote:

Oui, mais, dans, disons 3 ans, tu te retourneras vers ton département
ingéniérie quand tu commenceras à avoir des soucis,

Pas seulement pour le maintien,
il va aussi avoir des soucis quand je lui demanderai de me fournir des
sorties à partir d'archives :-(

il le précise d'ailleurs : "un petit raffinement d'interface".

<mauvaise foi>

Ha ! tu l'admets :-)

Euh, il parlait bien de SQLonneries, il me semble, pas de PHPonneries ou
autres...

Faut bien avouer que ces SQLonneries faut s'les farcir.

Il accuse quand même SQL d'être un système dépassé, indébuggable,
vieillot et impossible à utiliser, il me semble.

A t-il tord ?
Il doit bien il y avoir une nouveauté décoiffante qui se pointe à
l'horizon ?

L'interface doit je
pense bien être distinguée de ce qu'il y a derrière.

C'est bien ça qui pêche.
Le manque d'outil d'interfaçage.
Enfin je crois ?
Bien qu'ici :
<http://www.versiontracker.com/php/search.php?action=search&str=sql&plt%5B%5D=macosx>
p't'et' bien qu'il y a de quoi ?

[... une suite d'égarements ]

??

Ben oui, des chicornages HS.

Je me propose pour le développement en AW.

Je suis désolé, votre proposition, bien qu'

Rhâ la la ! Bien déçu.

Vous ne pourrez jamais être d'accord.

Je ne fais que donner des arguments, j'aime bien FMP, je l'utilise
moi-même, il a ses avantages, c'est dire. Je ne trouve pas qu'il fasse
des applis merveilleusement belles au regard de l'interface de Mac OS X,

Bon, y a longtemps que je n'ai pas regardé FM
et il est certain qu'à l'époque il n'était pas vraiment "aqua"

il nécessite aussi un énorme travail de mise en place de l'interface
surtout quand il doit être mis dans les mains d'utilisateurs novices.

Même avec AW y a du boulot et pourtant il peut moins qu'un FM ou 4D.
Comme tu disais l'interface demande un maximum de réflexion.
Néanmoins, et à mon idée, sans commune mesure entre partir de rien (avec
son éditeur-texte) et un outil assez adapté.

Je ne cherche pas à dire que tous les développeurs qui tournent autour
de SQL sont des virtuoses,

Il vaudrait cependant mieux.
Je bricole MySql et je vois bien que c'est pas terrible.
Qu'après avoir transpiré à grosses gouttes un truc qui fonctionne enfin,
je suis bien certain que l'optimisation n'est pas au rendez-vous.

j'ai vu plein d'horreurs.

Oui ... l'ergonomie ... un métier.

disons que SQL est là depuis pas mal de temps, les dumps sont
connus et réinjectables, même à mon petit niveau dans ce domaine je l'ai
déjà expérimenté. Cela dit, des outils comme FMP sont aussi capables de
le faire. Disons que le côté open source d'un MySQL, sans être le saint
graâl (non, je n'ai pas dit qu'il fallait tout faire en open source,
pitié) assure aussi de pouvoir au moins refaire à minima ce que faisait
l'original, un FMP, si ça plie un jour, ben...

Je me te traduit :
c'est pas difficile de faire en MySql ce que faisait une appli FMP.
C'est ce que tu dis ?
P. Manet n'a pas l'air de le penser.

Pour tout dire, j'ai suivi la mise en place d'une grosse appli sur FMP
(grosse car pièce importante du département d'une entreprise de bonne
taille). Eh bien, le développeur, chevronné dans ce domaine, a passé
déjà énormément de temps à définir la structure de sa base, ensuite les
liaisons entre les éléments

Est-ce que ça n'aurait pas été pareil avec MySql ?
Les tables ne se définissent ni ne se créent toutes seules.
Pareil pour les clès de l'une à l'autre me semble-ce.

et, pour finir, beaucoup de temps avec les
utilisateurs pour leur simplifier la vie.

ergonomie ergonomie

Cependant, au vu de l'utilisation à travers un navigateur, on aurait
tout à fait pu avoir la même chose dans une autre BDD comme un SQL, la
preuve, on a même eu droit à une maquette dont l'interface ressemblait à
la version FMP lorsqu'il a fallu faire le choix, c'est dire...

Entre une maquette (un écran à boutons inopérants) et le définitif il y
a une marge, les 6 mois de l'évolution auraient-ils suffit ?

En gros on n'attend plus que l'outil type 4D/FMP pour produire en SQL.

AppleWorks ne saurait pas faire ? ;-)

J'attends les plug-in pour iWeb :-)

--
Stephane Moriaux et son [moins] vieux Mac

Classic sur les Macs modernes

10 réponses

Veuillez sélectionner un problème