> Sinon, la plateforme matérielle de l'inria c'est aussi http://www-sop.inria.fr/parallel/hardware.fr.html ou ça a évolué ?

Ca c'est un cluster de prod de l'unité de sophia antipolis. Et oui la page semble a jour. Pourquoi ?

[ Répondre ]

Tu pourras bidouiller du hardware d'ici quelques mois. Les portables Dell sont d'incroyablement mauvaise qualité (clavier, charnière ecran, prise de jeu générale, écran vraiment bof).

Quand tu as un remplacement à J+1 c'est pas important. Pour un laptop perso... Les laptop Dell c'est vraiment du jetable, moche et lourd.

[ Répondre ]

> En XML il faut toujours ecrire le parseur, ici rien a faire !

Autant je suis d'accord avec toi pour le reste. Autant cette affirmation est fausse. Tu as au moins une dizaine d'implémentations qui te font le mapping automatique XML vers langage Objet (idem pour les DB). Pour les perfs c'est autre chose.

Les deux solutions semblent complémentaires. XML beaucoup plus généraliste et puissant. Protocol Buffer offre beaucoup moins de fonctionalités qu'XML puisqu'il cible mieux ses utilisateurs potentiels. Il est donc plus concis et rapide en déportant les traitements possibles en XML de la lib vers le code utilisateur.

C'est une bonne chose d'avoir une nouvelle alternative puisque la plupart des gens utilisent du XML pour tuer une mouche. Et donc la valeur ajouté par forcement significative.

[ Répondre ]

> Et dire qu'on se plaignait de le lourdeur d'Emacs...

Effectivement. Encore plus que la lourdeur c'est surtout qu'eclipse est pas du tout conçu pour fonctionner avec des fichiers seuls (pas de projet).

Un bon éditeur XML ca serait pas du luxe, quand je vois le nombre de mecs qui éditent du XML avec vim et se tapent 25 essais d'exécution alors qu'un éditeur validant permet de régler le truc en 5 secondes.

> Pour le XPath qui est plus parlant, ça dépend vraiment des gens.

Tu peux faire des trucs bien moches avec toutes les technos.

Reste que six mois après tu comprends encore assez facilement ce que l'expression suivante fait.

my $nodeset = $job_xml->find('//*/child/child[statu=\'REGRESSION\']/className/text()');
foreach my $node ($nodeset->get_nodelist) {
print "\t", "NEW ", XML::XPath::XMLParser::as_string($node), "\n";
}


Si tu peux formater en CSV; alors CSV ou XML sont plus ou moins équivalents. Cela dit il est plus facile de rajouter des attributs ou des éléments à un fichier XML en gardant tes outils qu'en CSV. De même tu peux représenter beaucoup plus de concept. Bref tout est question de dosage en fonction des objectifs et contraintes que tu as.

[ Répondre ]

Eclipse marche vraiment pas mal. Que ce soit pour l'édition de XSD ou de fichier plus classiques.

Le problème c'est que beaucoup de gens semblent utiliser XML pour stocker trois valeurs qui serait tout aussi bien en CSV.

L'interet d'XML c'est les outils qu'il y a autour et qu'ils sont facile à modifier. Pas de parser a réinventer, XPath, XQuery, XSLT, Xinclude, pas mal d'API pour la serialization automatique etc. C'est pas parfait mais ca fait gagner un temps fou de développement et pour faire évoluer les fichiers. Pour des fichiers de conf c'est plus douteux, mais au moins ca permet d'avoir une complétion "universelle".

Par contre si c'est pour faire communiquer deux processus proprio avec des contraintes de performance alors ca vaut peut être le coût de réinventer la roue. Et c'est la que se place "Protocol Buffers".

Récemment j'ai fait des stats sur les résultats des test unitaires et fonctionnels des 10 000 derniers builds d'un projet. Chaque résultat d'un build est stocké dans un ou plusieurs fichier XML, et le schema a évolué 3/4 fois. Apres 10 minutes d'XSLT j'avais tout reformaté en un gros fichier CSV, uploadé ca sur un cluster Hadoop DFS et commencé a sortir des stats avec Pig.

Je n'ai réinventé aucun outil. Du logiciel qui pond le fichier, à celui qui le transforme. Et une expression XPath reste toujours plus parlante qu'une série de grep | cut | awk | cut | sort | uniq. Et franchement, y'a plus intéressant à faire que de la manipulation de fichier dans l'informatique !

[ Répondre ]

> non merci, c'est suffisamment écœurant, et j'ai pas envie de faire partie des "gens" qui ont fait en sorte que l'histoire se répète.

Tu ne fais pas parti des gens qui font l'histoire tout cours. Juste des pleureurs de l'internet.

Hormis cracher sur tout le monde sur linuxfr tu fais quoi ? Je réitère mon invitation du thread sur OpenJDK 6 à nous montrer tes contributions sous licence GPL. Après t'être permis de dénigrer tant de monde, la moindre des choses serait d'avoir des choses à montrer. Et ca n'excuserait en rien ton comportement. Allez, avec un peu de chance t'es même sur PACA comme ca tu pourras me les montrer en vrai.

[ Répondre ]

Tu es le bienvenu, mais essayes, ici du moins, de perdre les mauvaises habitudes qui font loi chez MS.

LOL PTDR

https://linuxfr.org/~Sam_from_MS/ regarde bien la date de création du compte et tu peux aussi voir l'historique des trolls journaux. Sont marrants ces jeunes quand même !

[ Répondre ]

https://linuxfr.org/~cykl/12505.html ca date de 2004; y'a du avoir des progrès depuis. Cela dit cgprof marchait vraiment très bien à l'époque.

[ Répondre ]

Pour l'utilisateur oui.

En général quand une boite choisie un modèle de double licence c'est pour ne pas qu'une boite concurrente puisse faire la même chose; les forcer à passer par toi. En gros tu veux éviter qu'un intégrateur se fasse le pognon tout seul alors que c'est toi qui développe.

Si ton business model ne prévoit pas ça, alors soit une simple GPL suffit soit tu fais du LGPL/BSD.

[ Répondre ]

Je faisais des golfs il y a 8 ans :-)

J'ai choisi cet exemple au hasard pour montrer que l'écosystème d'un langage est aussi très important. Clairement Perl n'a rien à prouver de ce point de vue là.

[ Répondre ]

Une migration de VCS c'est ultra couteux en temps. Là l'avantage c'est qu'on ne change rien pour les devs qui n'ont pas à se soucier des branches. Bref actuellement tout le monde est content de la solution.

Et effectivement l'intégration de git dans eclipse/netbeans/idea actuellement c'est vraiment pas ça. C'est de toute façon un facteur bloquant pour migrer.

[ Répondre ]

"svn merge" ne sait merger que des commits sans se souvenir si ils ont déjà été mergé ou non. C'est une commande qui ne devrait pas être destiné à l'utilisateur final.

svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.

Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.

Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:

1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.

2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !

3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.

4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.

Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.

Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.

[ Répondre ]

> Suivi des opérations de Merge (merge tracking) (implémentation non complète)

J'ai pas encore testé la 1.5 mais c'est une très mauvaise nouvelle.
C'est LA lacune de SVN. Impossible de gérer des branches, ca foire à chaque fois et on fini par faire un diff/patch à la main.

La seule façon de merger des branches sur un serveur subversion que j'ai trouvé c'est d'utiliser git-svn (qui envoi du paté)...

[ Répondre ]

> 1/ bloatware (qui a besoin d'un "framework" pour coder un pauvre bot IRC

framework = bibliothèque :-)

https://rome.dev.java.net/
https://pircbot.dev.java.net/
http://code.google.com/apis/youtube/overview.html
http://mina.apache.org/

Mina est 100x overkill mais j'avais envie de jouer avec. Si utiliser des libs c'est du bloat...

> la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu).

C'est con c'était le but et j'ai tout de même écrit une version python.

> Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500

Ca fait 500 lignes de code pour prendre ses entrées sur X chan IRC, telnet et parser régulièrement l'output XML du serveur d'intégration continue; dispatcher ces infos sur différents planet en fonction de la config chaque planet poussant les infos sur des flux RSS ou sur IRC.

> Mais je vois pas la portée de l'argument

Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.

> utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats

Non. Ca te fais prendre des universitaires qui n'y connaissent pas forcément grand chose en ingénierie logiciel :-)

[ Répondre ]

Pour le bullshit tu peux aller la : http://www.sun.com/2006-1113/feature/index.jsp

Mon interprétation personnelle est la suivante. Java à atteint son seuil de pénétration depuis un moment. Ils ne font pas d'argent sur J2SE, c'est destiné aux end users et il y a des implémentations de BEA et d'IBM tout aussi performantes.

Java n'a jamais réussi à pénétrer sur le Desktop (il y a des raisons techniques la) alors qu"on voit du mono débarquer ! Et il suffit de voir les réactions ici pour comprendre ce que pense la communauté du LL sur la stack Java.

Bref ca ne leur coutera pas plus cher, je ne pense pas qu'ils attendent d'énormes contributions hormis des portages vers des archi exotiques, et ils ont une chance de gagner des utilisateurs.

On peut noter que l'évolution de Java est depuis longtemps ouvert à la communauté (JCR/JCP). Ce qui a mal été compris est la volontée de Sun de n'avoir sous le nom Java que des implémentations qui passent le TCK (souvenez vous de la VM de microsoft). C'est la même stratégie que la mofo, si vous voulez notre nom alors vous respectez nos règles.

En dehors du JDK, la politique à la mode chez Sun c'est d'offrir des implémentation de référence des specs libres, et d"en tirer des versions supportées. On peut citer: glassfish (serveur J2EE), OpenDS (directory service), OpenSSO, Hudson (_LE_ serveur d'integration continue) etc.

C'est le mouvement général de Sun depuis quelques années. Rien qu'a voir le nombre de bloggers qu'ils mettent pour faire leur com. Après Sun a toujours changé d'avis tout le temps :-)

Mais rien que pour Hudson, merci khosuke et Sun !

[ Répondre ]

Il est clair que l'on perd des contributeurs. J'explique ici pourquoi la plupart des boîtes demandent la cession de copyright sur leur bébé. J'ai mis longtemps à l'admettre, mais dans la plupart des cas, gagner 3 contributeurs externes ne vaut pas de perdre la main sur ta base de code.

Y'a eu une présentation assez intéressante à javaOne cette année sur comment combiner communauté open Source et développement drivé par une entreprise:
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS(...)

(désolé il est tôt j'ai cliqué sur inutile au lieu de pertinent)

[ Répondre ]

On parle de contribution externes ici.

Sauf clause spéciale dans ton contrat, tu n'as pas ton mot à dire sur le code produit dans le cadre de ton travail. Et même un peu plus... Si tu bosses sur un logiciel de CAO et que tu fais un autre logiciel de CAO sur ton temps libre qui pourrait concurrencer le premier attends toi à recevoir une lettre du service juridique. De même que si tu bosses pour un projet sous GPL et que tu y contribues le WE attends toi à ce que le copyright de ce code revienne tout de même à l'employeur.

[ Répondre ]

As tu déjà créé ou participé à une boite qui développe du LL ?

Le modèle économique de Qt/MySQL est l'un des plus honnête et rationnel. Ta boite investie pour faire du logiciel libre, si la GPLte convient c'est tout bénef pour toi. Si tu veux faire du proprio tu casques une licence proprio. Et ca, ca n'est faisable que si tu gardes le copyright sur l´ensemble de la base du code.

Maintenant si MySQL/Qt change d'avis et décide de passer en proprio, il te reste les anciennes versions libres. À la communauté du LL de reprendre le bébé. Jusque ici elle avait tout eu gratis

La cession du copyright ce n'est pas fait par plaisir, c'est qu'autrement ta boite perd la possibilité de se retourner (un projet bloqué en GPLv2 seulement par exemple). Et même quand tu as la main sur toute la base du code, opensourcer ou changer de licence relève du parcours du combattant.

Investi plusieurs années de ta vie et de ton pognon pour créer une boite et tu changeras peut être d'avis. Si la FSF ou la fondation Apache demande la cession de copyright ce n'est pas pour rien ! KDE l'a compris dans la douleur.

Ca me tue les mecs a qui on donne des choses et qui trouvent encore le moyen de gueuler ! Tu peux forker Java si tu ne veux pas contribuer mainstream et garder ton copyright.

Mais tu sais, dans la vraie vie sur les projets importants, les contributeurs externes sont rares. Mysql table sur 6 patchs externes cette année. OpenOffice y'a pas plus de 10 commiters externes etc. Alors la communauté est plutôt gagnante dans le deal.

Toi qui ne manque pas de tout critiquer. Qu'à tu fais pour le LL aujourd'hui (et hier) ? Certains tentent de faire avancer les choses, même si on pourrait mieux faire, d'autres font la morale sur les forums. Tu es de quel coté ?

[ Répondre ]

Je suis complètement d'accord sur la notion de facilité et du cercle vicieux.
Je prends une vision pragmatique de développeur/chef de projet. Tu as un choix a faire maintenant tu fais quoi ? (il n'y a pas de réponse unique)

Cela dit dans facilité tu as aussi la notion de maturité des frameworks. Récemment j'ai voulu faire un bot IRC pour générer des flux RSS/mail (il mange aussi des connexions Telnet et récupéré des metadata sur des sites comme youtube). Je me suis donné le choix entre Ruby et Python. Mais après avoir comparé les docs/examples des modules dans les différents langages je me finalement suis rabattu sur Java alors que j'aurais bien scripté... Moins de 500 lignes au final.

D'un point de vue encore plus personnel, je me fou de la soit disant "beauté" du langage. Si j'écris 5 lignes de code au lieu de 10 je suis content. Mais ce qui m'importe le plus c'est de pouvoir faire les choses (outils, libs etc.), comprendre aisément du code de quelqu'un d'autre, avoir une base de code maintenable sur la durée, quand je code un lib avoir des utilisateurs potentiels et ne pas sortir mon soft 3 ans après avoir épuisé les crédits.

Et par pitié n'assimile pas une techno a quelques uns de ses utilisateurs: "si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java". Y'a un marché de dev Java important. Ca draine les déchets, c'est évident. Mais je pense pas régresser mentalement lorsque je passe du C au Java. Tout comme il serait bon de ne pas traiter d'imbéciles les mecs d'Apache, de Sun ou qui font des archis comme Yahoo, Ebay ou LinkedIn.
Dans l'informatique pro y'a 70% de boulets, faut bien qu'ils utilisent quelque chose. Tu n'y changeras rien (et ils ont une petite chance de faire moins de mal en Java qu'en C ou C++ :-) )

[ Répondre ]

> Quand on parle de bonne techno, dans le même thread que java, ça a tendance à me faire sourire. (facile on est vendredi).

Tu remplaces Java par J2EE et je suis d'accord avec toi :-) Souvent quand on parle de Java le gens pensent J2EE ou Java 1.2. Depuis ca a un peu évolué dans le bon sens tant en perf qu'en fonctionalités.

> Quelles sont les qualités de java

Facile à utiliser, lib standard assez complète, bon écosystème, portabilité aisée. En général tu fais facilement ce que tu veux. Tu passes plus de temps à faire des choses fun que réinventer la roue en général.

Ce n'est pas LA solution, et je n'irais pas l'utiliser pour n'importe quoi.

> Qu'est qui fait que java est robuste ?

Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.

> des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).

Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés). Si tu veux être viable à long terme il faut pouvoir attirer des gens et autant que possible faire le moins de travail toi même.

Attention je n'ai jamais dit que Java c'était LE truc génial et inégalé. C'est un outil adapté à certains problèmes qui a l'avantage d'être mainstream (et avec OpenJDK on peut espérer voir des gens du LL débarquer).

Même si tu ne veux pas faire de Java, réjouis toi de l'ouverture de Hotspot. Ca doit juste être un des bouts de code les mieux optimisés au monde. Il y a aussi pas mal de projet réutiliser la JVM, et ses perfs, pour d'autre langage (ca fait un .Net portable).

Après si quelqu'un veut discuter technique je pense avoir le background C et Java pour apporter quelques réponses sur les perfs etc.

[ Répondre ]