Le 18/06/2011 10:13, JKB a écrit :Avec des outils standardisés comme Graddle ou Maven, je peux recompiler
la plupart des projets Java du monde sans aucun prérequis sur ma
machine.
On fait la même chose avec tous les autres langage. Regarde un peu
pkgsrc sous NetBSD. Ce n'est pas une histoire de langage, mais de
protocole de compilation.
Sauf que Java n'est justement pas que son langage mais la foultitude
d'outils intégrés.
Je n'ai jamais compris pourquoi il fallait du XML dans des choses
comme ant ni pourquoi un makefile des familles ne fonctionne pas
pour compiler du Java.
Avec Maven, si tu préfères un POM en YAML ou en Groovy, c'est possible =)
Et ? C'est encore quelque chose qui n'est _pas_ intrisèque au
langage.
Si
L'utilisation de ces outils a été standardisé dans Java et quasiment
plus aucun projet ne se fait sans eux.
Dans ce cas, c'est que le type chargé d'écrire le makefile (ou la
version autoconf/automake) est un branque. Le makefile (ou le
configure) doit s'arrêter en signalant ce qu'il manque.
Généralement, ces bouts manquants sont disponibles dans les dépôts.
Quand je vois que Maven va aller te chercher dans un dépôt la dépendance
manquante ainsi que ses dépendances transitives et te mettre ça bien au
chaud sur ton disque (~/.m2) sans pourrir ton système, et ce quelque
soit ton système (Windows, BSD, Linux, Mac)…
Effectivement, tous les devs de Makefile sont des branques comme tu dis.
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Beuah... Déjà, lorsque je vois tous ces répertoires imbriqués les
uns dans les autres, j'ai envie de vomir.
Ça c'est l'IDE qui le gère.
Et si tu ne veux pas de répertoires imbriqués, c'est totalement possible.
Sauf que tu t'exposerais à des conflits avec tes dépendances si tes
dépendances fonctionnaient aussi comme ça.
En effet, comment faire la différence entre CollectionUtils.class de
Apache Commons et la mienne si tout est au même niveau ? Alors que chez
moi pas de soucis, une est dans fr.imirhil.openpki.utils.CollectionUtils
et l'autre dans org.apache.commons.utils.CollectionUtils. Rien que cela
t'évite les saloperies d'écrasement qu'on peut connaître avec C/C⁺⁺.
Et ? Si j'avais le temps, je te ferais la même chose en C (quitte à
utiliser à fond cpp ou m4 et un patchwork de bibliohtèques bien senties).
Et pour ta gouverne, le nombre de lignes n'est pas un facteur discriminant.
Le nombre d'instructions le serait déjà un peu plus.
502 statements si tu préfères =)Portabilité limitée aux systèmes qui embarquent une JVM conforme. Ça
s'est considérablement amélioré ces derniers temps avec openjkd,
mais durant très longtemps, les seules cibles étaient celles qui
avaient une JVM Sun officielles. Avec C/C++/Fortran, ça compile
partout ou presque. Avec Java, j'ai eu des tas de problèmes avec
blackdown, J9, Superwaka et autres. La portabilité Java, c'est de la
poudre aux yeux, d'autant que lorsque tu commences à faires de
choses subtiles, il faut _aussi_ trouver les paquets à importer.
http://mvnrepository.com/ ?
162.000 librairies qui n'attendent que toi…
Toutes disponibles en 4 lignes de XML dans le POM.
Tu m'en fais de même en C ou en C⁺⁺ ?
Oui si j'en avait le temps et l'envie.En si peu de code ?
À peu près.En si peu de temps (un week-end) ?
Certainement pas, mais ce serait réutilisable et portable.
Alors là je demande à voir =)
Le 18/06/2011 10:13, JKB a écrit :
Avec des outils standardisés comme Graddle ou Maven, je peux recompiler
la plupart des projets Java du monde sans aucun prérequis sur ma
machine.
On fait la même chose avec tous les autres langage. Regarde un peu
pkgsrc sous NetBSD. Ce n'est pas une histoire de langage, mais de
protocole de compilation.
Sauf que Java n'est justement pas que son langage mais la foultitude
d'outils intégrés.
Je n'ai jamais compris pourquoi il fallait du XML dans des choses
comme ant ni pourquoi un makefile des familles ne fonctionne pas
pour compiler du Java.
Avec Maven, si tu préfères un POM en YAML ou en Groovy, c'est possible =)
Et ? C'est encore quelque chose qui n'est _pas_ intrisèque au
langage.
Si
L'utilisation de ces outils a été standardisé dans Java et quasiment
plus aucun projet ne se fait sans eux.
Dans ce cas, c'est que le type chargé d'écrire le makefile (ou la
version autoconf/automake) est un branque. Le makefile (ou le
configure) doit s'arrêter en signalant ce qu'il manque.
Généralement, ces bouts manquants sont disponibles dans les dépôts.
Quand je vois que Maven va aller te chercher dans un dépôt la dépendance
manquante ainsi que ses dépendances transitives et te mettre ça bien au
chaud sur ton disque (~/.m2) sans pourrir ton système, et ce quelque
soit ton système (Windows, BSD, Linux, Mac)…
Effectivement, tous les devs de Makefile sont des branques comme tu dis.
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Beuah... Déjà, lorsque je vois tous ces répertoires imbriqués les
uns dans les autres, j'ai envie de vomir.
Ça c'est l'IDE qui le gère.
Et si tu ne veux pas de répertoires imbriqués, c'est totalement possible.
Sauf que tu t'exposerais à des conflits avec tes dépendances si tes
dépendances fonctionnaient aussi comme ça.
En effet, comment faire la différence entre CollectionUtils.class de
Apache Commons et la mienne si tout est au même niveau ? Alors que chez
moi pas de soucis, une est dans fr.imirhil.openpki.utils.CollectionUtils
et l'autre dans org.apache.commons.utils.CollectionUtils. Rien que cela
t'évite les saloperies d'écrasement qu'on peut connaître avec C/C⁺⁺.
Et ? Si j'avais le temps, je te ferais la même chose en C (quitte à
utiliser à fond cpp ou m4 et un patchwork de bibliohtèques bien senties).
Et pour ta gouverne, le nombre de lignes n'est pas un facteur discriminant.
Le nombre d'instructions le serait déjà un peu plus.
502 statements si tu préfères =)
Portabilité limitée aux systèmes qui embarquent une JVM conforme. Ça
s'est considérablement amélioré ces derniers temps avec openjkd,
mais durant très longtemps, les seules cibles étaient celles qui
avaient une JVM Sun officielles. Avec C/C++/Fortran, ça compile
partout ou presque. Avec Java, j'ai eu des tas de problèmes avec
blackdown, J9, Superwaka et autres. La portabilité Java, c'est de la
poudre aux yeux, d'autant que lorsque tu commences à faires de
choses subtiles, il faut _aussi_ trouver les paquets à importer.
http://mvnrepository.com/ ?
162.000 librairies qui n'attendent que toi…
Toutes disponibles en 4 lignes de XML dans le POM.
Tu m'en fais de même en C ou en C⁺⁺ ?
Oui si j'en avait le temps et l'envie.
En si peu de code ?
À peu près.
En si peu de temps (un week-end) ?
Certainement pas, mais ce serait réutilisable et portable.
Alors là je demande à voir =)
Le 18/06/2011 10:13, JKB a écrit :Avec des outils standardisés comme Graddle ou Maven, je peux recompiler
la plupart des projets Java du monde sans aucun prérequis sur ma
machine.
On fait la même chose avec tous les autres langage. Regarde un peu
pkgsrc sous NetBSD. Ce n'est pas une histoire de langage, mais de
protocole de compilation.
Sauf que Java n'est justement pas que son langage mais la foultitude
d'outils intégrés.
Je n'ai jamais compris pourquoi il fallait du XML dans des choses
comme ant ni pourquoi un makefile des familles ne fonctionne pas
pour compiler du Java.
Avec Maven, si tu préfères un POM en YAML ou en Groovy, c'est possible =)
Et ? C'est encore quelque chose qui n'est _pas_ intrisèque au
langage.
Si
L'utilisation de ces outils a été standardisé dans Java et quasiment
plus aucun projet ne se fait sans eux.
Dans ce cas, c'est que le type chargé d'écrire le makefile (ou la
version autoconf/automake) est un branque. Le makefile (ou le
configure) doit s'arrêter en signalant ce qu'il manque.
Généralement, ces bouts manquants sont disponibles dans les dépôts.
Quand je vois que Maven va aller te chercher dans un dépôt la dépendance
manquante ainsi que ses dépendances transitives et te mettre ça bien au
chaud sur ton disque (~/.m2) sans pourrir ton système, et ce quelque
soit ton système (Windows, BSD, Linux, Mac)…
Effectivement, tous les devs de Makefile sont des branques comme tu dis.
Je vais te donner un exemple tout bête :
https://bitbucket.org/aeris/openpki/src
Beuah... Déjà, lorsque je vois tous ces répertoires imbriqués les
uns dans les autres, j'ai envie de vomir.
Ça c'est l'IDE qui le gère.
Et si tu ne veux pas de répertoires imbriqués, c'est totalement possible.
Sauf que tu t'exposerais à des conflits avec tes dépendances si tes
dépendances fonctionnaient aussi comme ça.
En effet, comment faire la différence entre CollectionUtils.class de
Apache Commons et la mienne si tout est au même niveau ? Alors que chez
moi pas de soucis, une est dans fr.imirhil.openpki.utils.CollectionUtils
et l'autre dans org.apache.commons.utils.CollectionUtils. Rien que cela
t'évite les saloperies d'écrasement qu'on peut connaître avec C/C⁺⁺.
Et ? Si j'avais le temps, je te ferais la même chose en C (quitte à
utiliser à fond cpp ou m4 et un patchwork de bibliohtèques bien senties).
Et pour ta gouverne, le nombre de lignes n'est pas un facteur discriminant.
Le nombre d'instructions le serait déjà un peu plus.
502 statements si tu préfères =)Portabilité limitée aux systèmes qui embarquent une JVM conforme. Ça
s'est considérablement amélioré ces derniers temps avec openjkd,
mais durant très longtemps, les seules cibles étaient celles qui
avaient une JVM Sun officielles. Avec C/C++/Fortran, ça compile
partout ou presque. Avec Java, j'ai eu des tas de problèmes avec
blackdown, J9, Superwaka et autres. La portabilité Java, c'est de la
poudre aux yeux, d'autant que lorsque tu commences à faires de
choses subtiles, il faut _aussi_ trouver les paquets à importer.
http://mvnrepository.com/ ?
162.000 librairies qui n'attendent que toi…
Toutes disponibles en 4 lignes de XML dans le POM.
Tu m'en fais de même en C ou en C⁺⁺ ?
Oui si j'en avait le temps et l'envie.En si peu de code ?
À peu près.En si peu de temps (un week-end) ?
Certainement pas, mais ce serait réutilisable et portable.
Alors là je demande à voir =)
Le 18/06/2011 12:49, JKB a écrit :Je vais aller vomir... Un makefile, c'est simpliste à côté...
C'est certes verbeux, mais c'est beaucoup plus concis au final que le
Makefile puisque je ne m'occupe que de lister ce que j'ai besoin (4
lignes pour chaque dépendence à intégrer).
Maven se charge de TOUT le reste (téléchargement, intégration au projet,
compilation, test, site web, déployement, versionning…).
Et l'IDE est aussi là pour t'aider en te masquant le XML au final :
http://blog.frankel.ch/wp-content/resources/top-eclipse-plugins-i-wouldnt-go-without/m2eclipse-overview-tab.jpg
http://www.jussimononen.info/wp-content/uploads/2010/03/maven_pom_editor.png
Le 18/06/2011 12:49, JKB a écrit :
Je vais aller vomir... Un makefile, c'est simpliste à côté...
C'est certes verbeux, mais c'est beaucoup plus concis au final que le
Makefile puisque je ne m'occupe que de lister ce que j'ai besoin (4
lignes pour chaque dépendence à intégrer).
Maven se charge de TOUT le reste (téléchargement, intégration au projet,
compilation, test, site web, déployement, versionning…).
Et l'IDE est aussi là pour t'aider en te masquant le XML au final :
http://blog.frankel.ch/wp-content/resources/top-eclipse-plugins-i-wouldnt-go-without/m2eclipse-overview-tab.jpg
http://www.jussimononen.info/wp-content/uploads/2010/03/maven_pom_editor.png
Le 18/06/2011 12:49, JKB a écrit :Je vais aller vomir... Un makefile, c'est simpliste à côté...
C'est certes verbeux, mais c'est beaucoup plus concis au final que le
Makefile puisque je ne m'occupe que de lister ce que j'ai besoin (4
lignes pour chaque dépendence à intégrer).
Maven se charge de TOUT le reste (téléchargement, intégration au projet,
compilation, test, site web, déployement, versionning…).
Et l'IDE est aussi là pour t'aider en te masquant le XML au final :
http://blog.frankel.ch/wp-content/resources/top-eclipse-plugins-i-wouldnt-go-without/m2eclipse-overview-tab.jpg
http://www.jussimononen.info/wp-content/uploads/2010/03/maven_pom_editor.png
Le 18/06/2011 10:00, JKB a écrit :Le rapport avec la choucroute ? Et si je préfère Netbeans ?
Netbeans s'intègre très bien aussiEt si au
contraire je suis un vimiste tendance fanatique ?
Pas de soucis non plus, c'est ce que j'utilise sur les serveurs sans XUn langage est bon
ou mauvais indépendamment de l'IDE utilisée. S'il faut un IDE, il y
a déjà AMHA un problème.
L'IDE n'est pas obligatoire, il n'est là que pour aider à aller vite
(complétion automatique, intégration de Maven…)
Pas seulement au démarrage. Avec java (et tous les trucs objets), il
te faut un architecte du début à la fin. Mon expérience de vieux con
me dit que :
1/ commencer un projet en fonctionnel est très dur, mais plus on
arrive à la fin et plus c'est facile ;
2/ terminer un projet en objet est très dur, plus on arrive à la fin
et plus les conneries du début entravent le développement.
J'ai jamais eu aucun de ce genre de soucis en dev Java.
Et une fois l'architecture (standard donc qui se retrouve sur chaque
projet ensuite) bien entrée dans la tête des devs (y compris débutant),
ça roule généralement tout seul.
Dans ma boîte, la formation aux outils Java est estimée à 3 semaines,
après quoi ils sont autonomes sur TOUS les projets Java.
Et la formation est « productive » au sens où elle a lieu sur de vrais
projets en cours, donc sans perte de temps, et avec des exemples
concrets d'application.
Le 18/06/2011 10:00, JKB a écrit :
Le rapport avec la choucroute ? Et si je préfère Netbeans ?
Netbeans s'intègre très bien aussi
Et si au
contraire je suis un vimiste tendance fanatique ?
Pas de soucis non plus, c'est ce que j'utilise sur les serveurs sans X
Un langage est bon
ou mauvais indépendamment de l'IDE utilisée. S'il faut un IDE, il y
a déjà AMHA un problème.
L'IDE n'est pas obligatoire, il n'est là que pour aider à aller vite
(complétion automatique, intégration de Maven…)
Pas seulement au démarrage. Avec java (et tous les trucs objets), il
te faut un architecte du début à la fin. Mon expérience de vieux con
me dit que :
1/ commencer un projet en fonctionnel est très dur, mais plus on
arrive à la fin et plus c'est facile ;
2/ terminer un projet en objet est très dur, plus on arrive à la fin
et plus les conneries du début entravent le développement.
J'ai jamais eu aucun de ce genre de soucis en dev Java.
Et une fois l'architecture (standard donc qui se retrouve sur chaque
projet ensuite) bien entrée dans la tête des devs (y compris débutant),
ça roule généralement tout seul.
Dans ma boîte, la formation aux outils Java est estimée à 3 semaines,
après quoi ils sont autonomes sur TOUS les projets Java.
Et la formation est « productive » au sens où elle a lieu sur de vrais
projets en cours, donc sans perte de temps, et avec des exemples
concrets d'application.
Le 18/06/2011 10:00, JKB a écrit :Le rapport avec la choucroute ? Et si je préfère Netbeans ?
Netbeans s'intègre très bien aussiEt si au
contraire je suis un vimiste tendance fanatique ?
Pas de soucis non plus, c'est ce que j'utilise sur les serveurs sans XUn langage est bon
ou mauvais indépendamment de l'IDE utilisée. S'il faut un IDE, il y
a déjà AMHA un problème.
L'IDE n'est pas obligatoire, il n'est là que pour aider à aller vite
(complétion automatique, intégration de Maven…)
Pas seulement au démarrage. Avec java (et tous les trucs objets), il
te faut un architecte du début à la fin. Mon expérience de vieux con
me dit que :
1/ commencer un projet en fonctionnel est très dur, mais plus on
arrive à la fin et plus c'est facile ;
2/ terminer un projet en objet est très dur, plus on arrive à la fin
et plus les conneries du début entravent le développement.
J'ai jamais eu aucun de ce genre de soucis en dev Java.
Et une fois l'architecture (standard donc qui se retrouve sur chaque
projet ensuite) bien entrée dans la tête des devs (y compris débutant),
ça roule généralement tout seul.
Dans ma boîte, la formation aux outils Java est estimée à 3 semaines,
après quoi ils sont autonomes sur TOUS les projets Java.
Et la formation est « productive » au sens où elle a lieu sur de vrais
projets en cours, donc sans perte de temps, et avec des exemples
concrets d'application.
Ça reste à prouver. Pour ma part, je suis convaincu du contraire
parce qu'un code à interface fonctionnelle sera réutilisable
beaucoup plus facilement. Si la mise au point est plus longue, sa
durée de vie sera aussi supérieure. Je n'ai encore jamais vu un code
java réutilisé plusieurs années après sa conception initiale.
Généralement, les projets repartent presque d'une feuille blanche et
le code ancien n'est pas réutilisé.
Ce n'est certainement pas plus immonde que ce qui est écrit plus
haut. En tout cas, ça n'est certainement pas plus compliqué et ça se
fait avec quelques macros en C.
Non. Je suis convaincu que les types qui développent boost sont très
bons. Ce n'est pas pour cela que ce n'est pas un goufre à mémoire.
Quand tu veux faire quelque chose de générique, avec des classes qui
héritent les unes des autres, tu te retrouves toujours à gâcher de
la mémoire.
Ça reste à prouver. Pour ma part, je suis convaincu du contraire
parce qu'un code à interface fonctionnelle sera réutilisable
beaucoup plus facilement. Si la mise au point est plus longue, sa
durée de vie sera aussi supérieure. Je n'ai encore jamais vu un code
java réutilisé plusieurs années après sa conception initiale.
Généralement, les projets repartent presque d'une feuille blanche et
le code ancien n'est pas réutilisé.
Ce n'est certainement pas plus immonde que ce qui est écrit plus
haut. En tout cas, ça n'est certainement pas plus compliqué et ça se
fait avec quelques macros en C.
Non. Je suis convaincu que les types qui développent boost sont très
bons. Ce n'est pas pour cela que ce n'est pas un goufre à mémoire.
Quand tu veux faire quelque chose de générique, avec des classes qui
héritent les unes des autres, tu te retrouves toujours à gâcher de
la mémoire.
Ça reste à prouver. Pour ma part, je suis convaincu du contraire
parce qu'un code à interface fonctionnelle sera réutilisable
beaucoup plus facilement. Si la mise au point est plus longue, sa
durée de vie sera aussi supérieure. Je n'ai encore jamais vu un code
java réutilisé plusieurs années après sa conception initiale.
Généralement, les projets repartent presque d'une feuille blanche et
le code ancien n'est pas réutilisé.
Ce n'est certainement pas plus immonde que ce qui est écrit plus
haut. En tout cas, ça n'est certainement pas plus compliqué et ça se
fait avec quelques macros en C.
Non. Je suis convaincu que les types qui développent boost sont très
bons. Ce n'est pas pour cela que ce n'est pas un goufre à mémoire.
Quand tu veux faire quelque chose de générique, avec des classes qui
héritent les unes des autres, tu te retrouves toujours à gâcher de
la mémoire.
Le 18/06/2011 14:32, JKB a écrit :Ça reste à prouver. Pour ma part, je suis convaincu du contraire
parce qu'un code à interface fonctionnelle sera réutilisable
beaucoup plus facilement. Si la mise au point est plus longue, sa
durée de vie sera aussi supérieure. Je n'ai encore jamais vu un code
java réutilisé plusieurs années après sa conception initiale.
Généralement, les projets repartent presque d'une feuille blanche et
le code ancien n'est pas réutilisé.
Spring ? Hibernate ? Apache Commons ? SLF4J ? JUnit ? Hamcrest ? DBUnit
? JAXB ? Axis ?
J'en passe et tant d'autres…
La force de Java est de n'avoir à réaliser le code métier de
l'application, tout le reste (bdd, log, conf, test…) existe déjà et
coûte 4 lignes de XML à intégrer.
Donc oui on part toujours de 0 parce que le seul code qu'on réalise est
le code du client !
Si je bosse dans du ferroviaire, je ne fais que du ferroviaire dans mon
code, pas de gestion de BDD.
Si je fais du nucléaire, je ne fais que du nucléaire, pas de gestion du
fichier de conf.
Si je fais de la biométrie, je ne fais que de la biométrie, pas de
gestion des web services.
Le code obtenu est donc quasiment 100% métier et donc effectivement très
difficilement réutilisable sur un autre projet (faudrait déjà avoir le
droit de le faire vis-à-vis de notre client final…).
Ce n'est certainement pas plus immonde que ce qui est écrit plus
haut. En tout cas, ça n'est certainement pas plus compliqué et ça se
fait avec quelques macros en C.
J'attend la solution avec plaisir alors =)
Et si tu considères que les macros sont des choses propres, évolutives
et maintenables…
Non. Je suis convaincu que les types qui développent boost sont très
bons. Ce n'est pas pour cela que ce n'est pas un goufre à mémoire.
Quand tu veux faire quelque chose de générique, avec des classes qui
héritent les unes des autres, tu te retrouves toujours à gâcher de
la mémoire.
La généricité est à mettre là où elle a un sens.
Je n'irais pas rendre générique le code métier d'une application de
biométrie parce que j'ai de toutes façons de très fortes chances de ne
jamais pouvoir m'en resservir plus tard.
Mais je rend générique ma couche d'accès aux données pour être
indépendantes du projet voire du moteur de base de données. Ou encore
mes librairies de gestion des fichiers de conf qui seront 100%
réutilisables.
Boost est l'exemple même du frameworks totalement bloated qui a voulu
faire de la généricité là où elle n'avait aucun intérêt (trop bas
niveau) : array, image, buffer, CRC, exception, io, math, random…
Exactement le type de code qu'on va devoir faire justement de manière
non générique pour des raisons de conso mémoire ou de performances de
notre cœur métier.
Avec Boost, on va avoir le centre du système générique donc peu
performant et la périphérie (plus accessoire) non générique.
Spring fait plus ou moins la même taille mais se concentre sur des
choses très haut niveau où la généricité a du sens : authentification,
accès à la bdd, MVC, moteur de workflow, logging.
Le cœur du métier reste à ta charge et sera spécifique donc performant.
Mais toutes les options qui relèvent plus de l'ergonomie et du design
sont déjà toutes faites de manière générique et réutilisable.
Et il y a toutes les chances du monde pour que ton client te demande
plutôt des évos sur la périphérie que sur le cœur du métier (qui au
final évolue très peu).
Du genre se coupler à un annuaire LDAP pour l'authentification ou
d'envoyer les logs du cluster à un syslog que de changer l'algo de
reconnaissance des empreintes digitales ou le format de stockage de ces
empreintes…
Le 18/06/2011 14:32, JKB a écrit :
Ça reste à prouver. Pour ma part, je suis convaincu du contraire
parce qu'un code à interface fonctionnelle sera réutilisable
beaucoup plus facilement. Si la mise au point est plus longue, sa
durée de vie sera aussi supérieure. Je n'ai encore jamais vu un code
java réutilisé plusieurs années après sa conception initiale.
Généralement, les projets repartent presque d'une feuille blanche et
le code ancien n'est pas réutilisé.
Spring ? Hibernate ? Apache Commons ? SLF4J ? JUnit ? Hamcrest ? DBUnit
? JAXB ? Axis ?
J'en passe et tant d'autres…
La force de Java est de n'avoir à réaliser le code métier de
l'application, tout le reste (bdd, log, conf, test…) existe déjà et
coûte 4 lignes de XML à intégrer.
Donc oui on part toujours de 0 parce que le seul code qu'on réalise est
le code du client !
Si je bosse dans du ferroviaire, je ne fais que du ferroviaire dans mon
code, pas de gestion de BDD.
Si je fais du nucléaire, je ne fais que du nucléaire, pas de gestion du
fichier de conf.
Si je fais de la biométrie, je ne fais que de la biométrie, pas de
gestion des web services.
Le code obtenu est donc quasiment 100% métier et donc effectivement très
difficilement réutilisable sur un autre projet (faudrait déjà avoir le
droit de le faire vis-à-vis de notre client final…).
Ce n'est certainement pas plus immonde que ce qui est écrit plus
haut. En tout cas, ça n'est certainement pas plus compliqué et ça se
fait avec quelques macros en C.
J'attend la solution avec plaisir alors =)
Et si tu considères que les macros sont des choses propres, évolutives
et maintenables…
Non. Je suis convaincu que les types qui développent boost sont très
bons. Ce n'est pas pour cela que ce n'est pas un goufre à mémoire.
Quand tu veux faire quelque chose de générique, avec des classes qui
héritent les unes des autres, tu te retrouves toujours à gâcher de
la mémoire.
La généricité est à mettre là où elle a un sens.
Je n'irais pas rendre générique le code métier d'une application de
biométrie parce que j'ai de toutes façons de très fortes chances de ne
jamais pouvoir m'en resservir plus tard.
Mais je rend générique ma couche d'accès aux données pour être
indépendantes du projet voire du moteur de base de données. Ou encore
mes librairies de gestion des fichiers de conf qui seront 100%
réutilisables.
Boost est l'exemple même du frameworks totalement bloated qui a voulu
faire de la généricité là où elle n'avait aucun intérêt (trop bas
niveau) : array, image, buffer, CRC, exception, io, math, random…
Exactement le type de code qu'on va devoir faire justement de manière
non générique pour des raisons de conso mémoire ou de performances de
notre cœur métier.
Avec Boost, on va avoir le centre du système générique donc peu
performant et la périphérie (plus accessoire) non générique.
Spring fait plus ou moins la même taille mais se concentre sur des
choses très haut niveau où la généricité a du sens : authentification,
accès à la bdd, MVC, moteur de workflow, logging.
Le cœur du métier reste à ta charge et sera spécifique donc performant.
Mais toutes les options qui relèvent plus de l'ergonomie et du design
sont déjà toutes faites de manière générique et réutilisable.
Et il y a toutes les chances du monde pour que ton client te demande
plutôt des évos sur la périphérie que sur le cœur du métier (qui au
final évolue très peu).
Du genre se coupler à un annuaire LDAP pour l'authentification ou
d'envoyer les logs du cluster à un syslog que de changer l'algo de
reconnaissance des empreintes digitales ou le format de stockage de ces
empreintes…
Le 18/06/2011 14:32, JKB a écrit :Ça reste à prouver. Pour ma part, je suis convaincu du contraire
parce qu'un code à interface fonctionnelle sera réutilisable
beaucoup plus facilement. Si la mise au point est plus longue, sa
durée de vie sera aussi supérieure. Je n'ai encore jamais vu un code
java réutilisé plusieurs années après sa conception initiale.
Généralement, les projets repartent presque d'une feuille blanche et
le code ancien n'est pas réutilisé.
Spring ? Hibernate ? Apache Commons ? SLF4J ? JUnit ? Hamcrest ? DBUnit
? JAXB ? Axis ?
J'en passe et tant d'autres…
La force de Java est de n'avoir à réaliser le code métier de
l'application, tout le reste (bdd, log, conf, test…) existe déjà et
coûte 4 lignes de XML à intégrer.
Donc oui on part toujours de 0 parce que le seul code qu'on réalise est
le code du client !
Si je bosse dans du ferroviaire, je ne fais que du ferroviaire dans mon
code, pas de gestion de BDD.
Si je fais du nucléaire, je ne fais que du nucléaire, pas de gestion du
fichier de conf.
Si je fais de la biométrie, je ne fais que de la biométrie, pas de
gestion des web services.
Le code obtenu est donc quasiment 100% métier et donc effectivement très
difficilement réutilisable sur un autre projet (faudrait déjà avoir le
droit de le faire vis-à-vis de notre client final…).
Ce n'est certainement pas plus immonde que ce qui est écrit plus
haut. En tout cas, ça n'est certainement pas plus compliqué et ça se
fait avec quelques macros en C.
J'attend la solution avec plaisir alors =)
Et si tu considères que les macros sont des choses propres, évolutives
et maintenables…
Non. Je suis convaincu que les types qui développent boost sont très
bons. Ce n'est pas pour cela que ce n'est pas un goufre à mémoire.
Quand tu veux faire quelque chose de générique, avec des classes qui
héritent les unes des autres, tu te retrouves toujours à gâcher de
la mémoire.
La généricité est à mettre là où elle a un sens.
Je n'irais pas rendre générique le code métier d'une application de
biométrie parce que j'ai de toutes façons de très fortes chances de ne
jamais pouvoir m'en resservir plus tard.
Mais je rend générique ma couche d'accès aux données pour être
indépendantes du projet voire du moteur de base de données. Ou encore
mes librairies de gestion des fichiers de conf qui seront 100%
réutilisables.
Boost est l'exemple même du frameworks totalement bloated qui a voulu
faire de la généricité là où elle n'avait aucun intérêt (trop bas
niveau) : array, image, buffer, CRC, exception, io, math, random…
Exactement le type de code qu'on va devoir faire justement de manière
non générique pour des raisons de conso mémoire ou de performances de
notre cœur métier.
Avec Boost, on va avoir le centre du système générique donc peu
performant et la périphérie (plus accessoire) non générique.
Spring fait plus ou moins la même taille mais se concentre sur des
choses très haut niveau où la généricité a du sens : authentification,
accès à la bdd, MVC, moteur de workflow, logging.
Le cœur du métier reste à ta charge et sera spécifique donc performant.
Mais toutes les options qui relèvent plus de l'ergonomie et du design
sont déjà toutes faites de manière générique et réutilisable.
Et il y a toutes les chances du monde pour que ton client te demande
plutôt des évos sur la périphérie que sur le cœur du métier (qui au
final évolue très peu).
Du genre se coupler à un annuaire LDAP pour l'authentification ou
d'envoyer les logs du cluster à un syslog que de changer l'algo de
reconnaissance des empreintes digitales ou le format de stockage de ces
empreintes…
Je n'ai jamais dit le contraire. Il faut seulement que la foultitude
et demi des outils intégrés soient disponibles partout. Ce qui
revient à la même chose que savoir si la libx du C est disponible
sur telle ou telle cible.
Je préfère un makefile de barbu.
Et c'est dramatique. Parce qu'un tas de choses qui devraient être
simples sont complexifiés à l'extrème. Il n'y a _aucune_ raison
d'avoir remplacé un makefile par un truc bouffi de XML.
Et c'est parfaitement idiot, parce que c'est local à ton compte.
Tant que tu es seul sur ta machine, ça va.
Non, c'est intrinsèque à java et à son schéma de recherche de
classe que tu retrouve dans les sources (import) et dans les
fichiers jar.
Pardon ? Les namespaces du C++ ne sontpas fait pour les chiens.
Quant au C, il est parfaitement possible de régler le problème une
fois pour toute avec des macros.
Personnellement, lorsque j'écris un
projet en C, mon makefile modifie à la volée le nom des fonctions
humainement lisible en quelque chose qui n'écrasera rien.
Ce qui
doit te déranger, en C, c'est que tu dois faire cela à la main et
faire attention à ce que tu fais.
Et combien de bibliothèques de qualité ?
Je t'ai déjà dit que je n'avais pas le temps, mais des trucs comme
ça, je n'arrête pas d'en faire en C. Tu peux aller voir mes
productions.
Je n'ai jamais dit le contraire. Il faut seulement que la foultitude
et demi des outils intégrés soient disponibles partout. Ce qui
revient à la même chose que savoir si la libx du C est disponible
sur telle ou telle cible.
Je préfère un makefile de barbu.
Et c'est dramatique. Parce qu'un tas de choses qui devraient être
simples sont complexifiés à l'extrème. Il n'y a _aucune_ raison
d'avoir remplacé un makefile par un truc bouffi de XML.
Et c'est parfaitement idiot, parce que c'est local à ton compte.
Tant que tu es seul sur ta machine, ça va.
Non, c'est intrinsèque à java et à son schéma de recherche de
classe que tu retrouve dans les sources (import) et dans les
fichiers jar.
Pardon ? Les namespaces du C++ ne sontpas fait pour les chiens.
Quant au C, il est parfaitement possible de régler le problème une
fois pour toute avec des macros.
Personnellement, lorsque j'écris un
projet en C, mon makefile modifie à la volée le nom des fonctions
humainement lisible en quelque chose qui n'écrasera rien.
Ce qui
doit te déranger, en C, c'est que tu dois faire cela à la main et
faire attention à ce que tu fais.
Et combien de bibliothèques de qualité ?
Je t'ai déjà dit que je n'avais pas le temps, mais des trucs comme
ça, je n'arrête pas d'en faire en C. Tu peux aller voir mes
productions.
Je n'ai jamais dit le contraire. Il faut seulement que la foultitude
et demi des outils intégrés soient disponibles partout. Ce qui
revient à la même chose que savoir si la libx du C est disponible
sur telle ou telle cible.
Je préfère un makefile de barbu.
Et c'est dramatique. Parce qu'un tas de choses qui devraient être
simples sont complexifiés à l'extrème. Il n'y a _aucune_ raison
d'avoir remplacé un makefile par un truc bouffi de XML.
Et c'est parfaitement idiot, parce que c'est local à ton compte.
Tant que tu es seul sur ta machine, ça va.
Non, c'est intrinsèque à java et à son schéma de recherche de
classe que tu retrouve dans les sources (import) et dans les
fichiers jar.
Pardon ? Les namespaces du C++ ne sontpas fait pour les chiens.
Quant au C, il est parfaitement possible de régler le problème une
fois pour toute avec des macros.
Personnellement, lorsque j'écris un
projet en C, mon makefile modifie à la volée le nom des fonctions
humainement lisible en quelque chose qui n'écrasera rien.
Ce qui
doit te déranger, en C, c'est que tu dois faire cela à la main et
faire attention à ce que tu fais.
Et combien de bibliothèques de qualité ?
Je t'ai déjà dit que je n'avais pas le temps, mais des trucs comme
ça, je n'arrête pas d'en faire en C. Tu peux aller voir mes
productions.
Et après, on récupère du code moisi.
Je ne vois pas comment
assimiler en trois semaines tout ce qu'il faut pour utiliser
correctement un bloatware comme java associé à un autre bloatware
comme Netbeans ou Eclipse.
Si on y arrive en trois
semaine, on a déjà de solides notions de POO. Sinon, c'est
parfaitement impossible (sauf à ne pas comprendre ce qu'on fait et à
utiliser des recettes toutes faites).
Et après, on récupère du code moisi.
Je ne vois pas comment
assimiler en trois semaines tout ce qu'il faut pour utiliser
correctement un bloatware comme java associé à un autre bloatware
comme Netbeans ou Eclipse.
Si on y arrive en trois
semaine, on a déjà de solides notions de POO. Sinon, c'est
parfaitement impossible (sauf à ne pas comprendre ce qu'on fait et à
utiliser des recettes toutes faites).
Et après, on récupère du code moisi.
Je ne vois pas comment
assimiler en trois semaines tout ce qu'il faut pour utiliser
correctement un bloatware comme java associé à un autre bloatware
comme Netbeans ou Eclipse.
Si on y arrive en trois
semaine, on a déjà de solides notions de POO. Sinon, c'est
parfaitement impossible (sauf à ne pas comprendre ce qu'on fait et à
utiliser des recettes toutes faites).
Mon
expérience me dit qu'il faut souvent oublier le code de la version
1 et repartir d'une page blanche (c'est même assez souvent vrai
lorsqu'on code en C++)
Mon
expérience me dit qu'il faut souvent oublier le code de la version
1 et repartir d'une page blanche (c'est même assez souvent vrai
lorsqu'on code en C++)
Mon
expérience me dit qu'il faut souvent oublier le code de la version
1 et repartir d'une page blanche (c'est même assez souvent vrai
lorsqu'on code en C++)
D'autant plus que les #ifdef/#define n'ont aucune justification dans le
code et ne sont là que pour faire plaisir au compilateur.
D'autant plus que les #ifdef/#define n'ont aucune justification dans le
code et ne sont là que pour faire plaisir au compilateur.
D'autant plus que les #ifdef/#define n'ont aucune justification dans le
code et ne sont là que pour faire plaisir au compilateur.
Le 18/06/2011 14:41, JKB a écrit :Je n'ai jamais dit le contraire. Il faut seulement que la foultitude
et demi des outils intégrés soient disponibles partout. Ce qui
revient à la même chose que savoir si la libx du C est disponible
sur telle ou telle cible.
La foultitude ne dépend que d'un seul prérequis : Maven
Tout le reste, c'est Maven qui va te le gérer et te l'intégrerJe préfère un makefile de barbu.
Rien ne t'empèche de faire un Makefile pour Java.Et c'est dramatique. Parce qu'un tas de choses qui devraient être
simples sont complexifiés à l'extrème. Il n'y a _aucune_ raison
d'avoir remplacé un makefile par un truc bouffi de XML.
En quoi le XML serait-il moins bon que la syntaxe Makefile ?
Surtout que mon POM se contente d'être déclaratif (ce dont j'ai besoin)
et non impératif (ce que j'ai à faire) comme dans un Makefile.Et c'est parfaitement idiot, parce que c'est local à ton compte.
Tant que tu es seul sur ta machine, ça va.
Non, un autre utilisateur récupérera la même chose que moi sur son
propre compte.
Si c'est l'espace-disque qui te gène, en 1 ligne de XML, je définit mon
dépôt à C:Repo ou /opt/repo hein
<localRepository>${user.home}/.m2/repository</localRepository>
Non, c'est intrinsèque à java et à son schéma de recherche de
classe que tu retrouve dans les sources (import) et dans les
fichiers jar.
Oui mais :
— L'IDE te masque cette hiérarchie très profonde
— Tu peux très bien faire un projet avec tout au même niveau
Il ne s'agit que de conventions communément admises et standardisées par
l'ensemble de la communauté Java comme étant de bonnes pratiques de
programmation.
Pardon ? Les namespaces du C++ ne sontpas fait pour les chiens.
Les namespaces ne te seront pas plus utiles si une de tes dépendances
utilise le même que toi…
En Java, cela ne peut pas arrivé puisque c'est une convention d'avoir un
package de la forme « dns inverse » . « projet »
Chaque namespace est donc garanti unique à travers le monde.
Quant au C, il est parfaitement possible de régler le problème une
fois pour toute avec des macros.
Que personne ne peut décemment considérer comme propre, maintenable et
évolutif.
Personnellement, lorsque j'écris un
projet en C, mon makefile modifie à la volée le nom des fonctions
humainement lisible en quelque chose qui n'écrasera rien.
Utilité ?
Ce qui
doit te déranger, en C, c'est que tu dois faire cela à la main et
faire attention à ce que tu fais.
À la main oui, cela me dérange.
Faire attention non, étant donné que je considère par exemple que les
devs Maven sont autrement plus compétents que moi pour savoir comment
gérer la compilation d'un projet et donc que je leur délègue avec joie
cette partie.
Je n'irais jamais regarder comment fonctionne le plugin
maven-compile-plugin, ce n'est pas mon domaine de compétence. Tout comme
ce n'est pas mon domaine de faire un ORM de BDD ou un système de
workflow. D'autres sont bien plus compétents que moi sur ces sujets et
ont toute ma confiance pour leurs librairies.
Mon métier est de faire une appli de reconnaissance d'empreintes
digitales ou de guider des métros, pas de me battre avec des Makefile ou
des bases de données.Et combien de bibliothèques de qualité ?
La plupart.
Déjà rien que les trucs de la fondation Apache,
celles de la fondation
Eclipse, les Atlasians, les Sonatype, les CodeHaus, les SpringSources…
Toutes celles-là passent par des process de QA totalement monstrueux
avant publication.Je t'ai déjà dit que je n'avais pas le temps, mais des trucs comme
ça, je n'arrête pas d'en faire en C. Tu peux aller voir mes
productions.
URL ?
Le 18/06/2011 14:41, JKB a écrit :
Je n'ai jamais dit le contraire. Il faut seulement que la foultitude
et demi des outils intégrés soient disponibles partout. Ce qui
revient à la même chose que savoir si la libx du C est disponible
sur telle ou telle cible.
La foultitude ne dépend que d'un seul prérequis : Maven
Tout le reste, c'est Maven qui va te le gérer et te l'intégrer
Je préfère un makefile de barbu.
Rien ne t'empèche de faire un Makefile pour Java.
Et c'est dramatique. Parce qu'un tas de choses qui devraient être
simples sont complexifiés à l'extrème. Il n'y a _aucune_ raison
d'avoir remplacé un makefile par un truc bouffi de XML.
En quoi le XML serait-il moins bon que la syntaxe Makefile ?
Surtout que mon POM se contente d'être déclaratif (ce dont j'ai besoin)
et non impératif (ce que j'ai à faire) comme dans un Makefile.
Et c'est parfaitement idiot, parce que c'est local à ton compte.
Tant que tu es seul sur ta machine, ça va.
Non, un autre utilisateur récupérera la même chose que moi sur son
propre compte.
Si c'est l'espace-disque qui te gène, en 1 ligne de XML, je définit mon
dépôt à C:Repo ou /opt/repo hein
<localRepository>${user.home}/.m2/repository</localRepository>
Non, c'est intrinsèque à java et à son schéma de recherche de
classe que tu retrouve dans les sources (import) et dans les
fichiers jar.
Oui mais :
— L'IDE te masque cette hiérarchie très profonde
— Tu peux très bien faire un projet avec tout au même niveau
Il ne s'agit que de conventions communément admises et standardisées par
l'ensemble de la communauté Java comme étant de bonnes pratiques de
programmation.
Pardon ? Les namespaces du C++ ne sontpas fait pour les chiens.
Les namespaces ne te seront pas plus utiles si une de tes dépendances
utilise le même que toi…
En Java, cela ne peut pas arrivé puisque c'est une convention d'avoir un
package de la forme « dns inverse » . « projet »
Chaque namespace est donc garanti unique à travers le monde.
Quant au C, il est parfaitement possible de régler le problème une
fois pour toute avec des macros.
Que personne ne peut décemment considérer comme propre, maintenable et
évolutif.
Personnellement, lorsque j'écris un
projet en C, mon makefile modifie à la volée le nom des fonctions
humainement lisible en quelque chose qui n'écrasera rien.
Utilité ?
Ce qui
doit te déranger, en C, c'est que tu dois faire cela à la main et
faire attention à ce que tu fais.
À la main oui, cela me dérange.
Faire attention non, étant donné que je considère par exemple que les
devs Maven sont autrement plus compétents que moi pour savoir comment
gérer la compilation d'un projet et donc que je leur délègue avec joie
cette partie.
Je n'irais jamais regarder comment fonctionne le plugin
maven-compile-plugin, ce n'est pas mon domaine de compétence. Tout comme
ce n'est pas mon domaine de faire un ORM de BDD ou un système de
workflow. D'autres sont bien plus compétents que moi sur ces sujets et
ont toute ma confiance pour leurs librairies.
Mon métier est de faire une appli de reconnaissance d'empreintes
digitales ou de guider des métros, pas de me battre avec des Makefile ou
des bases de données.
Et combien de bibliothèques de qualité ?
La plupart.
Déjà rien que les trucs de la fondation Apache,
celles de la fondation
Eclipse, les Atlasians, les Sonatype, les CodeHaus, les SpringSources…
Toutes celles-là passent par des process de QA totalement monstrueux
avant publication.
Je t'ai déjà dit que je n'avais pas le temps, mais des trucs comme
ça, je n'arrête pas d'en faire en C. Tu peux aller voir mes
productions.
URL ?
Le 18/06/2011 14:41, JKB a écrit :Je n'ai jamais dit le contraire. Il faut seulement que la foultitude
et demi des outils intégrés soient disponibles partout. Ce qui
revient à la même chose que savoir si la libx du C est disponible
sur telle ou telle cible.
La foultitude ne dépend que d'un seul prérequis : Maven
Tout le reste, c'est Maven qui va te le gérer et te l'intégrerJe préfère un makefile de barbu.
Rien ne t'empèche de faire un Makefile pour Java.Et c'est dramatique. Parce qu'un tas de choses qui devraient être
simples sont complexifiés à l'extrème. Il n'y a _aucune_ raison
d'avoir remplacé un makefile par un truc bouffi de XML.
En quoi le XML serait-il moins bon que la syntaxe Makefile ?
Surtout que mon POM se contente d'être déclaratif (ce dont j'ai besoin)
et non impératif (ce que j'ai à faire) comme dans un Makefile.Et c'est parfaitement idiot, parce que c'est local à ton compte.
Tant que tu es seul sur ta machine, ça va.
Non, un autre utilisateur récupérera la même chose que moi sur son
propre compte.
Si c'est l'espace-disque qui te gène, en 1 ligne de XML, je définit mon
dépôt à C:Repo ou /opt/repo hein
<localRepository>${user.home}/.m2/repository</localRepository>
Non, c'est intrinsèque à java et à son schéma de recherche de
classe que tu retrouve dans les sources (import) et dans les
fichiers jar.
Oui mais :
— L'IDE te masque cette hiérarchie très profonde
— Tu peux très bien faire un projet avec tout au même niveau
Il ne s'agit que de conventions communément admises et standardisées par
l'ensemble de la communauté Java comme étant de bonnes pratiques de
programmation.
Pardon ? Les namespaces du C++ ne sontpas fait pour les chiens.
Les namespaces ne te seront pas plus utiles si une de tes dépendances
utilise le même que toi…
En Java, cela ne peut pas arrivé puisque c'est une convention d'avoir un
package de la forme « dns inverse » . « projet »
Chaque namespace est donc garanti unique à travers le monde.
Quant au C, il est parfaitement possible de régler le problème une
fois pour toute avec des macros.
Que personne ne peut décemment considérer comme propre, maintenable et
évolutif.
Personnellement, lorsque j'écris un
projet en C, mon makefile modifie à la volée le nom des fonctions
humainement lisible en quelque chose qui n'écrasera rien.
Utilité ?
Ce qui
doit te déranger, en C, c'est que tu dois faire cela à la main et
faire attention à ce que tu fais.
À la main oui, cela me dérange.
Faire attention non, étant donné que je considère par exemple que les
devs Maven sont autrement plus compétents que moi pour savoir comment
gérer la compilation d'un projet et donc que je leur délègue avec joie
cette partie.
Je n'irais jamais regarder comment fonctionne le plugin
maven-compile-plugin, ce n'est pas mon domaine de compétence. Tout comme
ce n'est pas mon domaine de faire un ORM de BDD ou un système de
workflow. D'autres sont bien plus compétents que moi sur ces sujets et
ont toute ma confiance pour leurs librairies.
Mon métier est de faire une appli de reconnaissance d'empreintes
digitales ou de guider des métros, pas de me battre avec des Makefile ou
des bases de données.Et combien de bibliothèques de qualité ?
La plupart.
Déjà rien que les trucs de la fondation Apache,
celles de la fondation
Eclipse, les Atlasians, les Sonatype, les CodeHaus, les SpringSources…
Toutes celles-là passent par des process de QA totalement monstrueux
avant publication.Je t'ai déjà dit que je n'avais pas le temps, mais des trucs comme
ça, je n'arrête pas d'en faire en C. Tu peux aller voir mes
productions.
URL ?
